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.
It is not consistent at all, as an even cursory reading of your messages will
show. And this point in turn directly contradicts your stated goals of RFC 822
compatibility and transport independence.
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.
Really? This is the first time you've mentioned this. I've never encountered
such a system.
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.
Labelling issues aside, people try to send material in unsupported forms across
limited transports all the time. You don't fix this by changing the labels.
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.
No, you are proposing that they be part of the content-type, where they are
even less appropriate.
Of course the fact that this label is just the same as the existing C-T-E
mechanism, just split off into another field to make it more complex and to
introduce more silly states, means that it really accomplishes nothing other
than being incompatible.
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?
Force what? In general there is no correlation between content type information
and the transfer encoding used to transmit it. As such there is nothing that
"forces" new content types, be they text or otherwise to use one particular
C-T-E.
A given content type leads to some particular canonical format for an object.
And that's where it ends -- you cannot extrapolate from a canonical format to
the C-T-E. They are related in some cases but independent in general.
It requires an instance of an object to determine what C-T-Es are valid. It is
always the case that one of 7bit, 8bit, or binary will be valid, and
quoted-printable or base64 are always valid. Stever Crocker posted an excellent
explanation of this not long ago that I intend to incorporate into the MIME
specification.
Some content type definitions list preferred encodings (I wish that they didn't
do this), and some composite content types have specific restrictions on
encodings. That's as close as it gets to having content-types "force" specific
encodings.
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.
Sigh. This is getting tiresome. You said, AND I QUOTE, "I want the defaults to
be for arbitrary binary material". If you didn't mean to say this then DON'T
SAY IT.
And this of course contradicts your proposed labelling of content you described
in the previous message and in the previous paragraphs.
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?
Wrong again, I'm afraid. There is a HUGE difference between narrowing a
specification to make it clear that some things that used to be permissible are
not a good idea any more, and retroactively declaring illegal behavior that is
known to cause major problems as now being legal. The former is explicitly
allowed in the process (see RFC1123's deprecation of source routes for an
example), while the latter is not.
This is it for me. I have better things to do with my time than go in endless
circles with your ever-changing and mutually contradictory proposals. I am
unwilling to continue discussing any of this until you come up with a single
concrete proposal that explicitly states what you're trying to do and what
merits it has.
I'm outta here.
Ned