I realize we're drawing close to Santa Fe, but I want to quickly
bring up one more issue that we might want to discuss: whether
portable end-of-line markers should remain as part of BASE64 and
QUOTED-PRINTABLE.
I was one of those who asked for such a feature way back when. These
are useful when transporting record-oriented binary files around via
email - the record boundaries can be preserved and any octet can
appear within a record. I also feel that it is better to represent
newlines in Content-type: TEXT body parts as "end-of-record" rather
than "CR LF" (encoded in BASE64 or QUOTED-PRINTABLE), because mapping
the sender machine's end-of-line convention onto CR LF sometimes loses
important information.
On the other hand, there are some problems:
+ End-of-record markers exist in BASE64 and QUOTED-PRINTABLE but not in
Content-transfer-encoding: BINARY, so there's no way to translate a BASE64
or QUOTED-PRINTABLE body part into a BINARY body part. It's also not
obvious how to represent ends of lines when a Content-type: TEXT object is
encoded in a Content-transfer-encoding: BINARY body part. We could fix
this asymmetry by adding a record-delimiting mechanism to BINARY (Yuk!) or
by getting rid of end-of-line markers, or by getting rid of BINARY
encoding.
+ End-of-record markers make it more difficult to define a checksum that
is computed the same way with all of the different encodings that can
be used to send binary files.
+ End-of-record markers make RFC XXXX a bit longer and make the encodings
a bit more difficult to implement. It is also necessary to specify,
for each content-type, whether record boundaries are to be used; else
an encoder on (record-oriented) system A might include them when they
weren't needed, and a decoder on (stream-oriented) system B would have
to decide what to do with them. The existence of record markers here
provides another means to hinder interoperability.
Alternatives to record-markers:
+ For the purpose of sending "external" files via email, a Content-type:
BINARY/RECORD-ORIENTED could be defined which implemented a
record-delimiting mechanism independent of the content-transfer-encoding.
+ For content-types that require record-oriented data, the specification
for each type would have to define how record boundaries should be
represented. (This is far simpler than defining for *every* content-type
if and when record boundaries should be used.)
Keith