Re: [idn] Re: 7 bits forever!

["David Leung \(Neteka Inc.\)" <david@neteka.com>]

> > 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