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
Interesting discussion. I have two quick reactions:
(1) It is *vital* to have some way, especially in Base64 -- which I
think is more important than quoted-printable in this regard -- to have
a way in which the sender can canonically represent line boundaries and
immunize them from all of the little disasters (e.g., line wrapping)
that affect mail. Parts of the checksum discussion should reinforce
(i) the specifications for 8bit transport seem to be a considerable
distance behind RFC-XXXX in terms of "ready to finish up and advance to
the next stage",
(ii) binary can't be transported at all under RFC821,
(iii) neither RFC-ZZZZ nor the Prime proposal make provision for
binary transport. It is a placeholder in the former at the moment,
along with some arguments for not allowing it (ever), and, if I recall,
the latter does not address it.
(iv) Despite some apparent promises at Atlanta, no proposal for
binary, non-line-oriented transport have appeared on the list, only
assertions that this is needed.
(v) It would be possible to define a binary transport model that does
have effective portable end-of-line markers by the simple expedient of
requiring that anything that "looked like" CR, LF, or "." be quoted in
some way, thus providing a sort of hybred between "pure binary" and
Base64 and using line-and-character-oriented transport.
perhaps "Content-transfer-encoding: binary" ought to be handled with
the same treatment as mostly-undefined character sets. I.e., put in a
placeholder, provide for a future RFC to be written in the context of a
proposed standard binary transport RFC, and then prohibit its use until
that is done.