> 2. A gateway must NOT touch the checksum.
This is an impossible requirement to meet. Example -- I have a
gateway that turns a particularly unpleasant and unique word
processing format into plain ASCII. The format is proprietary --
there is no possible way to read it on the recipient system. The
choices are convert or drop it on the floor. Users will not accept
data loss that you get from dropping it on the floor. This means
that the gateway must convert this material. And this conversion
will change the checksum. There's no way to avoid it.
I would like to distinguish two kinds of gateways. In particular, there are
gateways that are present for the use of the general public, and I do mean
everyone. For example, there are a few "well-known" entry points in to and
out of BITNET, and in to and out of the UUCP world. Of course, there are
also well-known X.400/Internet gateways.
There are also gateways for getting in to and out of local environments, for
some definition of "local". If I understand your example above, it
precisely represents my "definition" of a local gateway.
If I am trying to get in and out of a homogeneous environment (proprietary
or otherwise), this qualifies as local to me. In this context, a "gateway"
is performing a specialized service for its users and it had better
recalculate the checksum after manipulating the message.
However, I stand firm that a gateway in general must not touch the checksum.
The checksum must be an end-to-end service.
Later in your message you expressed an apparent dislike for the X.400
gateway solution of "losing" data in messages. Those gateways are non-local
gateways by my definition and I support their policy. Is this an issue for
which you and I must agree to disagree?
Jim