On Fri, 27 Mar 1992 09:37:12 -0500 (EST) you said:
<nl>We're still talking about different problems here. There is NO ambiguity
about what the bits actually mean when text is encoded as base64. What there
is -- and I interpreted Laurence's concerns as matching my own, possibly
incorrectly -- is concern that the correct interpretation will not always be
made in certain environments. For example, if you have "application/text" in
base64, then you know it has CRLFs, but this isn't exactly optimized for ease
of implementation on many platforms where the convention, in the past, has
been to assume that the CRLF conversion was done "downstream". There's no
reason it can't work in base64, but if you use quoted-printable you may make
the implementation EASIER on many platforms. That's all I meant to imply. --
Nathaniel
I do believe no MIME expert should even suggest that a particular choice of
encoding method is a step toward the solution of some question. Remember,
something one sends in q-p can still arrive in base64....
Clearly, the fact that 'canonical representations' were introduced in the
latest draft create to need to state, for each new type/subtype, if the
canonical representation of this type includes a line break convention.
I suppose (am I right ?) that in the current set of definitions, text in all
its subtypes does, and all others don't.
For the original question : I like text/file. At least it makes clear that it
is text, and it automatically 'inherits' charset and line break convention
(despite the fact that the current text does not say so explicitly, maybe
it should). /AF