ietf-822
[Top] [All Lists]

RE: Comment on the draft MIME Part 1 document

1993-04-28 17:05:07
On RFC 1137: Note that I think Steve thinks it was a mistake.
It is not even referenced in the current gateway spec, RFC 1327, except
for this requirement:

   -    RFC 1137 shall not be followed when mapping to SMTP or to
        JNT Mail

The reason is that we have completely failed to make anything like a
tight fence between the "restricted encoding" and the "nonrestricted
encoding" parts of the RFC 822 worlds, let alone make that fence follow
RFC 1137 rules.

Speaking as someone who implemented the RFC1137 facility some time ago and who
has subsequently evaluated many attempts to use it, this is absolutely right.
When you actually implement RFC1137 you have to decide when to apply it and
when not to. Doing this forces you to define where the "fences" are, or, at a
minimum, provide a place where the person configuring the gateway can specify
this.

Setting aside the difficulty of actually configuring this sort of thing for
the moment, the RFC1137 has nevertheless proved to be very disappointing.

Distasterous results occur if anything manages to get past the fence without
conversion, so the fences more or less have to be dual (in the same sense that
a Delauney triangulation is dual to a Veroni diagram) to the allowed message
transfer pathways. This imposed requirement on the underlying transport service
is often hard or even impossible to enforce, even inside of an enclave.

As a result I've seen RFC1137 techniques used successfully in a couple of
enclave situations but that's about it. Moreover, it is fair to say that
RFC1137 is essentially a complete failure in the RFC822 world, since:

(1) The usual reason for using RFC1137 is to deal with hosts that cannot
    handle quoted mailbox specifications.
(2) The solution-space RFC1137 ends up being applicable to is restricted to
    enclaves,
(3) RFC822-incompliance is not so resticted, so solving for your enclave does
    not solve the problem.
(4) Enclave systems can usually be moved into RFC822-compliance; fixing them
    isn't significantly harder than imposing the necessary transport
    restrictions for RFC1137.

Mind you, I thought RFC1137 was the greatest at the time and I still think it
does make sense in some limited situations (which usually involve gatewaying
into and out of non-RFC822 environments whose transport connectively is well
understood). It just didn't turn out to be the general solution that was hoped
for. We live and learn...

So, if 1137 was to be useful, *every* system in the world would have
to understand both its own "real" address and its own "1137-ed" address,
because every now and then, the 1137-ed address would leak back out of
"restricted-land".

This is the obvious alterntive to enclave-style solutions. Unfortunately,
current deployment includes systems where RFC1137-ed addresses have been
assigned different meaning than their non-RFC1137-ed equivalents, so if we were
to insist that everyone recognize both forms (impossible) we'd still be up
against another insuperable obstacle.

All this does offer important insight into the issue of how RFC822 mailbox
specifications really work in the real world. My current position is that we
should not muck with any of this now; let's see how the current header
extensions do in widespread deployment. Once we're sure of their utility and
capability we'll be in a position to evaluate both them as well as RFC1137-type
approaches and see what makes the most sense.

                                Ned