The textual contents should not have been encoded in Binary. They should
labled as either 7-bit or 8-bit as appropriate. If the textual component
could have been represtended as 8-bit, it should have been. If it was
labeled as 8-bit textual data, there is no need to downconvert it when
transversing the nexted multipart. BDAT binary transport can be used to
transport all transport encodings, not just binary.
As for new content-transfer-encodings, I agree no new encodings are likely
for applications where there are existing if less effecient alternatives.
If a net-new application is pioneered for which there is not an installed
base, there would be little barrier to using a new content-transfer-encoding
with it. If I packaged MIME content-type: Smell/stinky into
content-transfer-encoding: compressedbinhex, there would be no net-loss of
interoperability.
Greg V.
-----Original Message-----
From: Dan Kohn [mailto:dan(_at_)dankohn(_dot_)com]
Sent: Monday, October 23, 2000 9:42 AM
To: GregV(_at_)ieee(_dot_)org
Cc: ietf-822(_at_)imc(_dot_)org
Subject: draft-vaudreuil-esmtp-binary2-03.txt
First, nice effort on this I-D. One question:
Note that at the time of this writing there are no mechanisms for
converting a binary MIME object into an 8-bit MIME object. Such a
transformation will require the specification of a new MIME content-
transfer-encoding.
Why can't the gateway descend the nested MIME tree, converting each binary
body part to 7bit base64, except for text entities, which can be confirmed
to be valid 8bit entities, unless they have more than 1000 characters per
line, in which case they can be base64 encoded? This is probably a lot more
trouble than it's worth, but doesn't it constitute a valid binary->8bit
gateway?
As it stands, the paragraph seems at odds with this note from RFC 2048:
IMPORTANT: The standardization of a large numbers of different
transfer encodings is seen as a significant barrier to widespread
interoperability and is expressely discouraged. Nevertheless, the
following procedure has been defined to provide a means of defining
additional transfer encodings, should standardization actually be
justified.
Am I correct in supposing that folks are unlikely to support any new
transfer encodings at this point?
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>