[idn] Re: 7 bits forever!

["Eric A. Hall" <ehall@ehsco.com>]

Keith Moore wrote:

> if you can somehow solve the PKI problem, you can make SMTP immune to
> forgeries and have it provide end-to-end integrity.  so far, nobody
> has managed to do this.

I am of the opinion that a new messaging framework -- including the
protocol and the data-format -- is going to be pretty much required for
all of the interrelated problems to be solved. Once the mental committment
to a new design model is made, most of the problems can be redefined as
solvable. In this regard, many of the current problems are due to the
current model. So change the model.

> if you can somehow figure out a way for anybody to type in a mailbox
> in any language on any keyboard, you can solve the i18n mailbox problem.

Certainly backwards-compatible access methods should be defined for the
mailbox names, just as they are necessary for the domain name.

> until then, there's very marginal value in replacing SMTP.  even then,
> it would probably be easier to upgrade SMTP than to replace it.

I think that depends on the approach. If we are only allowed to think of
ways to extend the current model into new territory while preserving 100%
backwards compatibility, we can abort right now. If instead we try to
build a new mail system that provides backwards compatibility ONLY when
communicating with a legacy system, it is much more feasible.

For example, let's say that a new message-transfer service is defined that
uses a new message structure, so that the e2e issues can really be dealt
with properly. In the new environement, perhaps the protocol only
exchanges multipart/container entities, and these have subordinate parts
of message/trace, message/headers and message/body, while ~From and ~To
and other 822-like headers are stored in the message/headers entity.

Mapping this to a legacy system is straightforward in principle: if the
new transport is not available on the destination, have the agent combine
portions of the message/headers entity with portions of the message/trace
entity, perform whatever conversions are needed, and then send the
message/body part over SMTP (possibly performing additional conversions
such as line-folding or base64).

So, yes, we still have to coexist with legacy systems, but 100%
compatiblity at all times is no longer the root design objective. By
redefining the design criteria, we are liberated from the design
constraints that are imposed by SMTP.

[I know there are plenty of flaws in the above. This is not a proposal,
but rather an argument to redefine the design criteria.]

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/