My point is, and has always been, that I would like to see C-T-E's of 7bit,
8bit, and binary removed from the MIME spec. This is consistent with every
message I have posted on this topic.
- 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.
A well-documented design flaw is still a design flaw. The fact remains that
there is software that uses "C-T-E: binary" in a manner it is not supposed
to. If there was a single C-T-E of "none" instead of the current three
non-encodings, this would not have happened, and will not in the future.
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.
No, I have not changed my argument mid-stream. I would like to see 7bit,
8bit, and binary removed from the list of valid C-T-E's. I am not proposing
the ranges above be new C-T-E's.
This still doesn't belong in the content-type information since it can apply
to
any content-type.
Exactly my point. The 7bit and 8bit C-T-E's are so limiting that they don't
even apply to all text types, so why force them on all types?
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'm not wandering around the point -- you just fail to see what it is. Maybe
that's my fault for not being clear enough. I don't want "binary" to be the
default -- I want it to go away entirely.
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.
Removing NULL from the list of valid chars. is also an incompatible change to
RFC 822. No?
Mike