ietf-822
[Top] [All Lists]

Re: draft-vaudreuil-esmtp-binary2-03.txt

2000-10-23 09:28:21
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?

It can, but this is beside the point. The point here is that if you have binary
material there is at present no encoding that turns true binary material into
true 8bit material. Both quoted-printable and base64 output materal in the 7bit
range, not in the 8bit range.

There is some potential that encoding(s) which output 8bit will be defined
eventially so keeping the option open seems like a good idea.

It is of course possible to convert a message that contains a mixture of binary
and 8bit parts into one that at most contains 8bit parts. But there's no path
from real binary to real 8bit.

This is probably a lot more
trouble than it's worth, but doesn't it constitute a valid binary->8bit
gateway?

Yes, but the note doesn't say that there aren't valid binary->8bit gateways, it
says that there's no encoding that has a binary input domain and an 8bit output
range. I really don't think this is at all unclear.

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.

I see no conflict here. Definition of additional encodings is discouraged but
it isn't prohibited. Indeed, there's a procedure in place for doing it. If
we didn't want new encodings we would not have defined such a procedure.

The point of the section was that there needs to be a really good reason
for new encodings. In the case of binary->8bit, the potential size
savings may be worth it.

Am I correct in supposing that folks are unlikely to support any new
transfer encodings at this point?

Not necessarily. The big issue with new encodings is how you can tell whether
or not a given destination can handle them. Work such as RESCAP has the
potential to provide this sort of information in a standardized way. And
it is also possible to use out of band information for this sort of thing.

See draft-freed-newenc-00.txt for some examples of at least two encodings
that may get standardized at some point.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>