John Klensin and I have batted this one around offline a bit, but
since it has no effect on the Internet proper (an EBCDIC gateway is
not, properly speaking, a concern of the Internet) we have not
discussed it on the list. I don't propose we start now -- this list
is busy enough, and apart from making sure that the necessary
infrastructure gateways need is present I don't think this sort of
stuff is an appropriate topic for this list.
There is quite a lot of email traffic between the Internet and BITNET,
so any change to the Internet email message format is going to affect
both nets. If the people on this list are responsible for RFC-XXXX, I
would think that this list is the right place to discuss this issue.
Just to close a loop...
(1) I do not want to comment at this time about various intra-BITNET
discussions that might ease the transition. They may not happen. If
they happen, they may not happen within the lifetime of anyone now
reading this list.
(2) While the number of gateways that are described within the BITNET
community with words like "official" and "INTERBIT" is fairly small and,
by agreement, they run exactly the same software, there are a huge and
growing number of hosts with connections to both BITNET and the
Internet. The overwhelming majority of those hosts have gateway
capability. It is rational to assume that a significant number of hosts
will be passing RFC-XXXX messages by simple conversion to EBCDIC (i.e.,
assuming they are plain ASCII RFC822 format) for years and years,
regardless of what decisions we, or "BITNET" make (as long as we use an
SMTP envelope).
As Erik points out, there is a lot of traffic between the two
networks. Although there are many glitches, most of it works very well
now, to the extent of being completely transparent to the end user. The
end users (on both sides of the gateways) will be very unhappy if they
perceive of interoperability problems where they perceived none before.
Explaining whose problem it is (MTA, gateway, sending UA, receiving
UA,...) won't help very much with that unhappiness.
(3) While "we" can't solve the problems of BITNET (or any other
connected network) for "them", we should avoid causing harm and making
things unnecessarily difficult. But, as Ned says, this list is busy
enough. I would suggest two things:
(i) We proceed to settle on whatever arrangements of headers, types,
subtypes, envelopes, coding, etc., make sense in the Internet context.
Once we have done that, we go back and review it all against whatever
strawman gateway sitations people can posit to make sure both that
adequate information is available to the gateway in an accessible form
to make conversion possible and that we have not made things
unnecessarily difficult. If that requires adapting our agreed-upon
solution, fine, but we will at least have decided what we consider
optimal for an internet-only solution. If nothing else, I think that
process converges more rapidly than trying to solve everything at once.
(ii) We try to remember that the classic Internet/IETF model of proof
by implementation was really designed around new protocols whose use
was optional. While it is still important with these mail extensions,
it is also the case that we are tampering with the protocols that
provide the service of computer networks that is most visible to most
users. I think this implies that we need to prove safety as well as
efficacy, and that is a tough demonstration.
--john