nsb(_at_)thumper(_dot_)bellcore(_dot_)com (Nathaniel Borenstein) writes:
The way I read the winds, people are starting to converge on a scheme where
the MTA must understand the internal semantics of message bodies and at a
7/8-bit boundary the MTA must do the translation of the message body.
If this impression is wrong, please correct me.
This is my impression as well.
Note that it should be quite possible to define what the conversions
are well enough ahead of time that they can be safely done. Most/all
of the time it will simply be conversions in & out of Base64, does
anybody think *this* cannot be done safely.
I do not feel that character set conversions are an appropriate thing
to do just for the purpose of getting a message through a 7-bit hop.
Instead this should only be done at the recipients UA.
Furthermore, there are 2 possible ways of determining the boundary condition:
1. [Find out before SMTP happens & convert message then]
2. [Find out while SMTP is happening & scramble to correct]
Method 1 is completely hopeless in a heterogeneous internet. It is
natural only in the situation of N-bit enclaves or islands in a sea of
M-bit MTAs and assuming that N-bit enclaves need not communicate with each
other using pure-N-bit protocols.
Method 2 makes strong assumptions about the design of an MTA, namely that
the SMTP client is supposed to orchestrate rerouting and translation
functions.
Yes .. this is a problem. In PP (er.. WIN/MHS) only method 1 can
be done, currently. PP (WIN/MHS) is pretty aggressive about going
into a message and playing around, but then X.400 allows for MTA's
to drop body parts if 1) the originator allows for this to happen,
and 2) a particular body part is not allowed/possible over a link.
An PP/WIN/MHS installation which supported RFC-822++ would include
a channel for exploding such a message (that is, split each body
part out into a separate file in the queue directory, and convert
notations over to X.400/P1/P2) and another for flattening a P1 message
into RFC-822++. WIN/MHS currently includes channels for handling
RFC-1154 mail this way.
It is quite possible for mail to arrive in one format and leave in
completely another.
It includes a collection of filter channels whose job is to massage
various details in a message. For instance "text" -> "fax" is a
possible conversion. The conversions (set of channels to be traversed)
to be performed are chosen at submission time. The parameters
governing this choice are set at run time in a configuration file.
It is not, currently, possible for the path to change once the
message has been submitted. However it is possible for a channel
to resubmit a message & have the conversions-to-be-done recalculated.
CONCLUSION-TO-THIS-STORY: PP & WIN/MHS can do either method. Method
number 2 is the harder to do; we'd hafta rewrite the SMTP channel
to detect the need.
I told this story because PP (WIN/MHS) is likely at the high-end of
complexity & capability for handling this sort of situation. But it is
not very adept at handling a need to backpeddle & reformat a message.
However, I'd be much more willing to do the work to support a new protocol
that brings with it real long-term benefits instead of patching up a protocol
(SMTP) that has limited potential.
[...]
The "new protocol" I'm alluding to would be a generic binary-transparent MTP.
(No, not X.400).
This idea was bandied about for awhile. I don't recall the conclusion
which was reached. But let me try to spell out a problem I see
with doing this.
The MTA still has the same decision to make. That is, between sending
the message through either a 7-bit or 8-bit wide pipe. The MTA will
discover which pipe to send it through in much the same way as Method 1
& Method 2 above. Which brings you back to the same problem of doing
format conversions and possibly having to backpeddle if the 8-bit pipe
isn't available at that moment.
What would induce us to write the software to do your MTP? And
once the software is written, what is to induce our customers to
start using it?
Performance comes to mind ... also the P1 portion of X.400 (the
envelope) has a lot of useful information in it beyond the sender and
recipients. Things like priority, the various per-recipient flags, and
so forth. SMTP does not handle these at all. If people are serious
about having a protocol to compete with X.400 then these message
attributes are necessary.
... I believe that letting the current proposals go ahead would
be a long-term detriment. That would be a shame.
Yes.. saddling people with 33% greater cost than necessary is a shame ..
David