When I said that PMDF can
handle NULLs and 8bit, I meant just that and no more. Binary is a completely
different kettle of fish. PMDF, like most of the other agents you list,
performs canonicalization operations on incoming material. It has to because
of
the vagarities of the real world. If it isn't line-oriented or if you use CR
or
LF for something other than line terminators things will NOT work properly.
If PMDF claims support for RFC 1652 and changes bare CR's, bare LF's, or LFCR
to CRLF, then it is broken. If you think about it for a second, handling
NULLs and 8bit (without newline conversions) and arbitrarily long lines gets
you a binary transport, whether you like it or not. It's not as efficient as
it could be, but it works. I've done it myself.
- While MIME tries to be a transport-independent spec,
it fails at this because of the close ties to SMTP
transport limitations.
This is fundamentally backwards. A specification that doesn't take the
limitations of existing transport into account is absolutely transport
DEPENDENT, in that it can only be used over some new transport that has none
of
the existing limitations. By taking the ramifications of existing transports
into account AND allowing for the use of improved transports in the future
MIME
achieves a degree of transport independence no other scheme has ever attained.
Yes we have base-64 and q-p for transport-independence. I agree 100% with
that. What I disagree with is that 7bit and 8bit carry around the baggage of
"short lines" (p. 14-15 of RFC 1521) and no NULL's (recent discussion).
I also disagree that binary is evil, as so many on this list seem to argue.
UNLABELED binary is, but if it is labeled, then what's the problem? It will
be encoded with base-64 or q-p if the transport can't handle it.
RFC 822 does not specify a
line length limit of 1000 characters for messages.
So what? Neither does RFC 821, for that matter. And neither does MIME.
Read them and see.
I'm very familiar with both of these specs. If MIME does not have a
line-length restriction, then why are 7bit and 8bit defined as consisting
of "short lines"? And you're right, the MIME spec. does not say 1000
characters. The only line length restrictions found in MIME are the 76
character limits for base-64 and q-p output. Could this be the reason
certain versions of Eudora refused to generate ANY lines longer than 76
characters?
- Having three "encodings" (Content-Transfer-Encoding)
that mean basically "no encoding was performed"
indicates a design flaw in MIME. (The information
they convey IS necessary, but belongs elsewhere.)
I disagree. I think this is probably the best design choice we ever made in
MIME.
The fact that roughly 2 pages of text are required to explain why there are 3
encodings that mean "no encoding has been done" troubles me. And not
everybody reads it all -- Steve Dorner pointed out at least one software
package that made decisions about how to treat text based on the C-T-E. Just
because it is well-documented (and I believe the explanations are very
clear), does not mean it can't be confusing to people.
- If 7bit, 8bit, and binary labels for structure are found
to be too ambiguous (I think so), then how about this:
Content-Type: text/plain; charset=iso-8859-1;
width=85; range=1-255;
This goes too far and leads to silly states, where the labels do not reflect
reality. So do 7bit, 8bit, and binary, for that matter, but you have to
balance
what information should be provided and what should not. You could put a
frequency table in there if it came right down to it.
Actually I thought there would be exactly four possibilities for this:
range ::= "0-255" | "0-127" | "1-255" | "1-127"
My whole point in this is I want to see the defaults be for arbitrary binary
material, without having to slap a "Content-Transfer-Encoding: binary" on
every part of every message. Binary is not an evil to be suppressed. It
is reasonable to believe that this is where we are headed.
Michael D'Errico
Software.com