If we can succeed in building a mail system which allows new, wonderful
email features without breaking all those folk using 7-bit UA/MTAs and all
those folk usings 8-bit UA/MTAs then people will build it and sell it and
buy it and use it. If we just say, 'oh, by the way, you'll have to discard
your existing 8-bit internetwork', RFC-XXXX will join hundreds of other well
intentioned RFCs on the scrap heap of history.
Viewing this from the user's perspective:
Joe User id provided with a UA connected to a mail system. Joe wants to send a
message to a group of addreses. The message includes some discussion, a
binary program, and the supporting documentation. Joe wants the UA to
allow for steps such as:
1. Compose discussion text.
2. Attach binary program.
3. Attach supporting documentation.
4. Provide addresses.
5. Send it.
Joe User should not have to know what type of mail systems or gateways this
will go through. Joe should not have to send the message in different
ways to different addresses. Joe does have a problem with the recipient's
UA being unable to handle the message.
I can explain to Joe that his UA is more (or less) capable than a recipient's
UA. I do not believe that I can convince Joe to use a UA that requires
knowledge of the underlying transport. Joe will find a different UA, a
different mail system, or a different administrator (there go my car payments).
The question is thus "How do we define a capable, user friendly environment
in which 7-bit and 8-bit UAs and MTAs can coexist?". We must allow
for migration but we cannot abandon the old or the new.
I want to build a UA that allows Joe to send his message. Joe is currently
connected to a 7-bit mail system. Joe's UA (not Joe himself) must be
aware of this and provide proper transfer encoding for those parts of the
message that are not acceptable to the 7-bit network. It must put the message
in the "native form" of the mail system to which it is connected.
If Joe's message is leaving his mail system, it passes through a gateway.
The gateway cannot reasonably determine whether this message will be delivered
to a UA in this next mail system or gatewayed further. It must therefore
put the message in the "native form" for this mail system. From my point
of view, it must therefore parse the message body and add or remove any transfer
encoding that is or is not appropriate. I agree that this is dangerous
ground and the possibility for errors is great but then nobody said writing
a gateway was easy.
The point in all of this is that a UA should be responsible for putting
a message in the format required by the mail system to which it is attached.
The MTAs in said mail system are responsible for delivering the message
within this mail system. A gateway then becomes a MTA or pair of MTAs
connected between two different mail systems.
One of the biggest advantages of RFC-XXXX was the definition of a standard
that allows me to implement such a gateway. To say that a gateway cannot
do conversions is to eliminate the need for the gateway. Joe User is not
going to buy "You can't get there from here".
Providing for 8-bit <-> 7-bit gateways is only part of the problem. I'm
looking at gatewaying mail systems that don't even resemble RFC822 but
have the functionality to do what Joe User wants to do.
RFC-XXXX goes a long way toward providing a standard for implementing
functionality that already exists in many proprietary mail systems. To
cripple it by not allowing a gateway to do message format conversions
does not seem a wise thing to do. Gateways will still exist there will just
be no standard for them. To burden each UA with the tasks that should be
taken care of at a properly implemented gateway also seems unwise.
I totally agree that faulty gateways will be written. However, they will
be written regardless of what is put in RFC-XXXX. To design tools such
that those inexperienced in their use cannot hurt themselves or anyone else
seems only to limit or preclude their use by those more experienced.
I agree that transfer encoding should be done only at the lowest level.
Let UAs worry about putting the message in "native form" and not about
what gateways it passed through. Let the gateway handle the parsing of
body parts and provide rules for doing it. Broken gateways will still
exist but the rest of us may be able to interoperate.
--
* Tom Moore NCR Corporation PCD-6 (513) 445-1373 *
* Consulting Analyst 1700 S. Patterson Blvd. VOICEplus 622-1373 *
* Network Applications Dayton, OH 45479
Tom(_dot_)Moore(_at_)DaytonOH(_dot_)NCR(_dot_)COM *