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.
Why do we have to be able to type the mailbox in any language on any
keyboard? For myself, I have two email address one chinese and one english,
if I want to send email to the chinese I will use my chinese one that better
represents my name, and if I send email to english only people I will use
the english one... No one is required to initiate an email to a people using
their i18n email address, just like if you don't speak Japanese why try to
talk to the Japanese with Japanese?! i18n email address is only for people
that their native language is not english to represents their name better in
their own community!! Or else I think this IDN problem will eventually need
everyone to go back to language schools to learn every language in teh world
: >
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 totally agree on this too!! I think adding ESMTP commands and new MIME
headers can 100% achieve this, by allow compliant new mail systems to be
able to handle 8bits and for existing mail systems it will be able to
fallback to ACE for transport(SMTP, etc) but still maintains the MIME header
as displayable 8bits, this will serve both the future and backward
compatibility.
David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com