Mark writes...
Although John's comments are correct in so far as they go, it should be clear
that John and I do represent different camps.
For the record, I'm against 8-bit character oriented transport too, on the
...
Since we are making statements for the record here, let me clarify my
own position.
-- first of all, that position has evolved (well, at least changed
:-), a lot, over the last nine or ten months, so I don't necessarily
want to be held to what I believed six months ago.
-- if I were convinced that the issue of 8bit character oriented
transport could be made to go away by banning it, I'd be at the walls of
Mark's camp, if not in it. While I would have said "Latin-based
alphabet-centric", possibly even extending to "alphabetic/phonetic
character-centric" (as distinct from ideographic), I largely agree with
the moral principles he raises.
-- my difficulty is that I don't think that issue will go away and,
more specifically, that the alternative to a normative way to do 8bit
character transport isn't "no 8bit character oriented transport", is, in
practice, going to be: "just send 8bit, pretend that receivers who get
into trouble are broken/ insufficiently robust, and stonewall on the
complaints". One of the other areas where Mark and I are in strong
agreement (and it was one of the few positions that I thought were
agreed upon that the WG didn't change in Atlanta) is that the latter is
a Real Bad Plan. Where we may not agree is that I believe that
"ignoring those folks" and/or taking a "we don't need an 8bit character
transport standard" position effectively encourages them.
-- so I am trying very hard, within the context of RFC-XXXX and the
constraints that came out of the WG "decisions" in Atlanta, to try to
plot a course between the rock and the hard place and to find compromise
positions that are (at least) barely tolerable to everyone.
Maybe it is hopeless. If it is, MTA designers should start making
plans about what they are going to do when they see 8bit characters
flying through (or at) SMTP servers without the protections of either
negotiated options or the structures and identifying information of
RFC-XXXX. This isn't paranoid fantasy, but an absolutely safe
prediction: people are doing this anyway and, unless we have an
"approved" alternative with which we can say "if you insist on doing
that, do it this way", they are going to keep it up and, arguably, their
numbers will expand.
In this context, I oppose binary transport for all the reasons Mark
and I have raised and one more: if it gets bound to 8bit character
transport extensions to SMTP, I think they will go down in flames
together, leaving the field open to the "just send 8bit" folks. People
who really want 8bit character transport, and see it as important to
them, should, I think, oppose binary transport *or any other clutter*
being added to SMTP: these combinations are much likely to lead to mass
opposition than to some coalition of "something for everyone" factions.
I think this is an area where Greg seriously disagrees with me (just to
identify another possible position) and that may be why some of these
issues keep coming up.
Two closing observations...
(1) Mark's technical objection is:
. it is going to be a lot of work to get things interoperable with
extant 7-bit software
We agree that this is a problem. I feel quite strongly that the
burden of figuring out how to make it work should fall largely on the
people who want 7-bit transport although, if it does not create
unreasonable complications, the RFC-XXXX community should listen
sympathetically to requests for changes or additions that would simplify
the process. RFC-ZZZZ posed one strawman way of dealing with this
problem: it takes the position that 8bit character transport is for
those who want to use it and that no provision at all should be
standardized for in-flight conversions. Making sure that 7bit stuff
arrives at 7bit boundaries, and that 8bit stuff doesn't, is strictly an
originator responsibility. In the best case of that model, people who
really want 8bit transport get to use it. In the worst case, servers
know that they are dealing with something odd, which is an improvement
over the "just send 8bit" camp.
The WG at the Atlanta meeting apparently didn't like that alternative
and wanted conversions specified. The minutes indicated promises of
specific proposals and even trial implementations. None have been
forthcoming, and all of the effort and discussion of trying to guess at
what those conversions might be, and how they might interoperate with
RFC-XXXX in a 7bit world has been done, as a gesture of goodwill toward
the "Atlanta decisions" by people--including Mark and myself--who are
not at all convinced that it is a good idea (and many of whom were not
in Atlanta to understand where this "decision" came from and what it
really means).
(2) The people who want to invent or reinvent an 8bit transport
proposal, or who would like to ban it entirely, might find it amusing to
actually read RFC-ZZZZ (also known as
draft-ietf-smtpext-8bittransport-00). After the last several months, my
major regret about that document is all of the material that was taken
out pre-Atlanta and for incorporation into a document that has never
really been circulated.
--john