[Top] [All Lists]

another issue: should end-of-line markers remain in RFC XXXX?

1991-11-13 23:15:35
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

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

+ 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.)


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