< I am convinced by JGM's argument that if subtypes of "message" can choose
< to allow or to disallow "base64" or "quoted-printable" encoding in the
< subtype definition, deploying the 8BITMIME SMTP extension will be
< impossible, because of the difficulty in deciding what to do when
< encountering an unknown message/* subtype with 8bit data.
<
< I am also close to the conclusion that ANY message/* type that contains
< non-7bit data and is not a Message/RFC822 with a MIME-Version: header will
< make it impossible to communicate successfully through an 8-to-7 bit
< gateway, but I'm willing to be convinced otherwise on that point. (Just
< tell me how!)
Yes, gatewaying message/non-rfc822 is a serious problem. For example, if you
receive an 8-bit mime message which has been encapsulated and split up using
message/partial, and need to send it across a 7-bit SMTP link, there's no
way to downgrade it to a 7-bit message unless you either:
o collect the entire message, downgrade to 7-bit mime, and split it up
again
or
o go illegal and ignore the restrictions on using base64 or
quoted-printable
content-transfer-encoding with message/*
< If the latter is true, should we go whole hog and say that ALL subtypes of
< MESSAGE, except for message/rfc822 with MIME headers, MUST have c-t-e
< 7bit???????
If the message had been downgraded to 7-bit before being encapsulated and
split up, this problem wouldn't be there. But of course, the gateway can't
force that. Or if we were allowed to introduce content-transfer-encodings of
base64 or quoted-printable, this problem wouldn't be there.
I'm tempted to recommend that this restriction be lifted before MIME becomes
standard. (This would be a pure extension since it's something which is
currently disallowed.) I know there were problems envisioned with allowing
base64 message/*, but the problems with not allowing it may be more serious.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com