If PMDF claims support for RFC 1652 and changes bare CR's, bare LF's, or LFCR
to CRLF, then it is broken.
I'm sorry, but this simply isn't true. The use of bare CR, LF, and LFCR
sequences in 8bitMIME is outside of the existing specifications and
requirements.
And as a practical matter, I cannot sell a mail system that doesn't
canonicalize bare LF into CRLF, since lots of systems violate the
specifications and just send LF over SMTP as their line terminator. Standards
take a back seat to reality on this one. This can even be turned off in PMDF
(and in sendmail I believe), in which case CR, LF, and LFCR sequences will be
preserved, but I've yet to find a site that managed to operate for more than a
few days with it disabled. People really don't like for their text mail to be
delivered as a single immensely long line punctuated with garbage characters.
(VMS uses counted records for text, so CR and LF characters are generally not
expected in text files.)
However, you will rapidly run into other problems if you try to send binary
material over an 8bitMIME channel. For example, there is no way to send a
binary object outside of a multipart structure that doesn't end with a CRLF
sequence using the 8bitMIME extension. Implementations are also free to impose
line length limitations on incoming SMTP (RFC821 states what the minimum
supported sizes are, but doesn't say you have to handle any more than that).
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.
Nope. There's more to it than this. At a minimum you need a different DATA verb
in SMTP. See above.
This is not what an 8bitMIME transport i for. I know it is what you would like
it to be for, but it isn't what it is for.
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).
This is the entire point of having them in there.
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.
You are asserting things that were never said. Binary is not evil. It is just a
different facility than 8bit, and requires support of a different sort to
handle it properly.
PMDF will soon support binary transport as well. But you will have to use the
binary extension and the BDAT command, not the 8bitMIME extension, to get it.
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"?
Please! There is a big difference between saying that the data has to consist
of short lines and saying there's a specific line length restriction. This
should be obvious.
Your assertion that MIME is incompatible with RFC822 rests on the assumption
that RFC822 is not line oriented. Well, I hate to have to be the one to break
the news, but RFC822 is line oriented (in fact it only supports the transfer of
US-ASCII plain text) regardless of whether or not there's a specific length
restriction specified.
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?
I have no idea. You'd have to ask the people who wrote Eudora. And what does
this have to do with the topic at hand anyway?
- 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.
Just a minute. First you claimed that there was a design flaw. I disagreed. Now
you claim that the specification is accurate and clear but confusing. The two
are orthogonal issues.
On confusion and broken implementations: Our purpose here is to arrive at
accurate and useful specifications. It is not to insure that nobody can ever
possibly read the resulting documents in a half-assed way and them implement
the wrong thing. No specification can ever assure us of this.
Nero Wolfe once said that one of the few tasks he would never undertake is that
of putting sense into a fool's brain. Standards writers would do well to heed
the implied advice here.
Actually I thought there would be exactly four possibilities for this:
range ::= "0-255" | "0-127" | "1-255" | "1-127"
Again you are changing your argument mid-stream -- this is a *very* different
proposal. If this is what you want, then fine -- get a consensus that there
need to be one or two additional unencoded transfer-encodings besides 7bit,
8bit, and binary. I don't think this is going to happen, but you are welcome to
try.
This still doesn't belong in the content-type information since it can apply to
any content-type.
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.
Boy, you sure do wander around the point! This is the first time that you have
ever mentioned that your goal is to get binary to be declared as the default.
I can tell you right now that this isn't going to happen, if for no other
reason than a binary default would constitute an incompatible change in RFC822.
Nevertheless, you are welcome to propose such a change if you want to.
Ned