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 don't find this line of reasoning to be very convincing.
First of all, it is simply incorrect to say that quoted-printable and/or base64
encodings on subtypes of message cause problems for 8-to-7 gateways. The reason
for this is pretty obvious: By definition something with a quoted-printable or
base64 encoding cannot contain any 8bit data!!! 8-to-7 gateways don't have
anything to do in such cases as a result.
Use of such encodings may cause major trouble when you go to read such a
message (the so-called nested encoding problem), but this is a separate issue
that would only be a problem with subtypes that are similar to message/rfc822.
The real problem for 8-to-7 gateways is caused by use of either 8bit or binary
encoding. Nothing more and nothing less. And since its inception MIME has
allowed the use of both the 8bit and binary encodings on message/rfc822. And
there has never been anything in MIME that would preclude using 8bit or binary
encodings on a new subtype of message.
The problem (obviously) arises when an 8bit or binary encoding is used on an
unknown subtype of message. Since message is a composite type, gateways have to
know how to get inside of each different sort of subtype in order to encode it
properly and avoid the nested encoding rule. And doing this requires gateway
reconfiguration at a minimum and possibly even additional code in every
gateway.
The change in the new MIME draft actually simplifies the addition of new
message subtypes somewhat rather than complicating it. Specifically, where it
makes sense to allow quoted-printable or base64 encoding, new subtypes of
message can now avail themselves of existing encoding facilities. This was not
possible before. But you still have to know how to handle each subtype. This
hasn't changed and I don't see a way of changing it short of an outright ban on
additional subtypes that require recursive processing. (This is essentially
what I'm going to propose below.)
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!)
How about this approach: Place an outright ban on the use of 8bit or binary
encoding on all subtypes of message other than rfc822. This lets 8-to-7
gateways use the following two step procedure:
(1) Is it message/rfc822? If it is, check to see if its encoded
using quoted-printable or base64 and if so, flag it as an error.
Otherwise handle message/rfc822 recursively.
(2) Is it encoded as 7bit, quoted-printable, or base64? Stop if it
is, and if it isn't flag it as an error.
I don't see any problems with this approach other than the fact that it
eliminates the possibility of registering a new subtype that behaves like
message/rfc822. On the other hand, standards can always be revised, and perhaps
having to revise the standard to add such a thing is a good idea.
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???????
I can live with this, but it really isn't necessary. The only encodings
that must be avoided on new subtypes of message are 8bit and binary. 7bit,
quoted-printable, and base64 are all fine, at least as far as 8-to-7
(and, for that matter, binary-to-8 and binary-to-7) are concerned.
Ned