Subject: Re: [idn] Moving Towards UTF8 vs ASCII(ACE) Forever

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Mar 2002 21:07:55 -0600

At 09:52 PM 3/20/2002 -0500, Edmon Chung wrote:
>An underlying question we must ask ourselves from all the discussions that
>have sprung up every now and then is:

and as luck would have it, the working group has asked itself that question 
many times, so we need not pursue it again.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: "Meritt James" <[email-masked]>
Date: Thu, 21 Mar 2002 09:08:32 -0500

Ah, but was there an implementable ANSWER?  THAT is the question!

-- 
James W. Meritt CISSP, CISA
Booz | Allen | Hamilton
phone: (410) 684-6566

---

From: "Edmon Chung" <[email-masked]>
Date: Wed, 20 Mar 2002 21:52:34 -0500

Do we wish to

1. eventually move the DNS towards UTF8/16 OR
2. do we want to stay with ASCII(ACE) for the rest of our lives?

If the answer is 1. then the IDN solution should take it into concern.  If
it is 2. then perhaps the IETF should revise some of its
internationalization policies.

I can see an arguement coming that says there is no draft on this, but if we
dont even get this fundamental question figured out, how can there be a
collective or meaningful effort towards a solution that makes most sense??

Edmon

PS. Perhaps we should have a show of hands or something about the real
"DIRECTION" that PEOPLE want to see with the internationalization of the
Domain Names.

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 21 Mar 2002 11:40:22 -0500

From: "Meritt James" <[email-masked]>
> Ah, but was there an implementable ANSWER?  THAT is the question!

Here is a simple architecture/roadmap possibility:

1. IDNA user-end plugin
    - this plugin does all the heavy lifting to encode and decode ACE and
display it properly for the user
    - servers does not upgrade.  Even administration side is kept as is,
allowing leakage for administrators
    - IDNA plugins must also be able to decode IDN(UTF8)/EDNS [This I will
call UDNA for this discussion]

2. UDNA DNS Server upgrade
    - DNS servers will now accept both ACE and IDN(UTF8)/EDNS requests and
provide consistent responses
    - IDNA plugins continue to send in ACE but will start to see UDNA
responses

3. UDNA for clients & everywhere
    - IDNA plugins begin to obsolete, new versions of application software
comes with UDNA built in.
    - In case DNS servers are not upgraded yet, clients will continue to use
the IDNA plugin which will work fine with the new UDNA application.
    - Other applications/servers upgrade to UDNA to accept UTF8 domains,
administrators might continue to see ACE leakage if the client still uses
IDNA to send requests, but UDNA requests will be viewable and manageable in
UTF8

4. UDNA
    - Slowly but certainly, we will move towards full UTF8 because
administrators will likely want to deal with UTF8 than ACE, especially for
say those admins in China who are dealing with IDNs frequently.

You should be able to find holes in it, but it is whether the general
concept is workable that is important.  If so, THEN, we can work on refining
the concept and putting it into a draft.  And one of the key things is that
UDNA MUST be included in an IDNA plugin to start with for the entire system
to be able to move out of ACE and into UTF8 completely eventually.  That is
why we cannot and should not leave it out for now.

Thoughts everyone?

Edmon

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 21 Mar 2002 14:54:36 -0500

Hi Dave

You seem to be repeating my words in a slightly different "tone"

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
> the answer was that it is not happening now and we need to make a
> transition that is independent of converting to utf-8 native.
>

My answer
> >And as I recall, the answer to the question is, allow me to summarize "we
> >will wait and see".  There has never been a definitive answer or decision
on
> >this as yet.

What is the difference.  Please enlighten me.

The result is still "it is not happening now", but the question is "will it
happen in eventually", you have not answered the question.  If it IS, then
we should start working NOW.  That is
my point.  If we collectively decide that it is NEVER going to happen and we
will stay with ACE FOREVER, then, we should stop here and live happily ever
after with ACE.  But if the general direction or consensus is to move
towards UTF8 eventually, then, we should start the work now.

Edmon

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Mar 2002 17:32:06 -0500

> 2. do we want to stay with ASCII(ACE) for the rest of our lives?

it's a false dichotomy.  

first, there are probably some purposes for which identifiers 
(including DNS names) should stay ASCII (and not even 10646
encoded as ASCII) for the forseeable purpose.  there are other
purposes for which IDNs are useful.

second, "ASCII for the rest of our lives" is a mischaracterization.
IDNA allows applications to accept and present IDNs in native
form, without requiring all applications and infrastructure to
upgrade before IDNs can be used.   IDNA is designed to maximize
the rate at which IDNs can be deployed.

users don't care whether IDN queries are encoded on the wire.
they only care about whether IDNs work for them.  IDNA puts the
user in a position to determine whether IDNs work for him -
a UTF-8 everywhere approache forces him to wait for everybody 
else to adopt IDNs before he can use them.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Mar 2002 00:30:37 -0000

Keith Moore writes:
> IDNA is designed to maximize the rate at which IDNs can be deployed.

I hereby declare that cs.utk.edu is an IDN. We will now spend twenty
years trying to convince all application programs to display it as the
international picture of an ostrich with his head in the sand.

Look, Keith, we've deployed an IDN in zero time! Infinite rate! You
didn't even have to touch your DNS records!

Boy, I'm glad that, when you faced the much smaller problem of non-ASCII
subject lines back in 1991, you and your buddies decided to ``maximize
the rate'' of deployment by inventing your own encoding mechanisms,
rather than giving in to the demands of 8-bit transparency. Oh, sure, we
still have quite a few display failures eleven years later, and users in
Europe are constantly sending raw ISO 8859-1 in violation of your 7-bit
requirement, and sendmail still has problems with UTF-8, and now we're
facing years of IDNA pain followed by years of IDNA-MAILBOX pain, but
you were able to _instantaneously_ deploy Quoted-Printable back in 1991,
and that's what matters! Brilliant!

Even better, your incisive design decisions mean that billions of people
will be able to continue using their 36-bit computers, which, as you
know, are incapable of processing character data in units other than 7
bits, because 36 is not divisible by 8, but it is divisible by 7, um,
well, except for the remainder of 1, but who's counting? The point is,
Keith, THANK YOU! You've made all our lives so much better! I hope
someday you can travel to Taiwan and meet some of your fans.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 21 Mar 2002 18:58:27 -0600

Keith Moore wrote:

> encoded as ASCII) for the forseeable purpose.

Agreed. Well-known data-types such as Message-ID are actually harmed if
they exist in multiple forms (this also includes the transliterated form
that results from IDNA). This is why implementation is a per-WG effort,
not a global mandate. However, the infrastructure (in the broadest sense)
should support native IDNs in order to facilitate the most effective
scoping for any WG.

> else to adopt IDNs before he can use them.

lol, speaking of false dichotomies

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

---

From: [email-masked]
Date: Fri, 22 Mar 2002 09:44:37 -0500

> rather than giving in to the demands of 8-bit transparency. Oh, sure, we

The MIME and ESMTP working groups had *quite* a bit of infighting on
that topic.  There was a large contingent that wanted to declare "just
send 8 bit" the standard. Re-reading RFC1428 and realizing that at the
time, there were a *LARGE* number of systems that broke badly if they
were handed 8 bit data.

You can't blame Keith for that one - there were a LARGE number of people
involved.  And there was a basic non-negotiable design goal for MIME that
had to be followed:

A MESSAGE HAD TO GET THERE INTACT EVEN IF IT PASSED THROUGH A NON-MIME-AWARE
SYSTEM.

This is in all-caps because it's important.  For instance, RFC2047-style
header encoding happened because you could *NOT* trust that all the systems
between here and there were 8-bit-clean (in fact, an 8-bit-clean system
was a rarity) - and if the third or fourth system that the mail passed
through happened to be non-MIME, it might do something nasty (like fold
characters in 128-255 down into the lower half, or bounce the message because
it was invalid RFC822 because RFC822 *clearly* says ASCII, and non-ASCII
is therefor illegal).

Let's take as an example the "native language" encoding of my name:

From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks <[email-masked]>

(That's a "small e with macron", Unicode 0113).

If you have a *better* suggestion than 2047-encoding of how to pass that
character in an e-mail header *that will survive passing through an
intermediary system that enforces strict RFC822*, please clue us in....

Why is this important?  Well.. think about this message.  I may have
an 8-bit-clean mailer.  You may have one.  But neither of us has the
authority to make sure that the software at ietf.org is able to deal.

Those who think the DNS is being overly strict in enforcing ASCII in
domain names are invited to consider the following:

1) RFC1035 says this in section 3.1:

  Although labels can contain any 8 bit values in octets that make up a
  label, it is strongly recommended that labels follow the preferred
  syntax described elsewhere in this memo, which is compatible with
  existing host naming conventions.  Name servers and resolvers must
  compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
  with zero parity.  Non-alphabetic codes must match exactly.

RFC2181, section 11, re-iterates that the DNS is codeset-agnostic.

So what do you know... the DNS spec is already using an N-bit-clean
length-data encoding.  So obviously there's some Very Evil Restriction
that makes it not allow non-ASCII.  And the favorite whipping boy here
is BIND, which by default restricts it (you can put 'check-names off;'
for a zone in the named.conf file, and you can put 'options no-check-names'
in your resolv.conf).

2) Why does it get restricted?  Consider the parsing issues involved if you
have a domain name that uses raw Unicode and embeds the character
known as "Malayalam Letter UU". A hint why this is Very Bad are available
at http://www.unicode.org/charts/PDF/U0D00.pdf

And of course, the true bugbear here is that you can create a domain name
that contains Malayalam Letter UU, and it will work Just Fine with all
the Neat New Software you've installed.

However, you have to deal with the reality that 90% of the users are
going to try to contact your site using either a web browser or an email
client shipped by one vendor - and that vendor hasn't shipped a version
compatible with Your New Neat Stuff.  So if you use some New Method that
breaks that software, you're not going to be talking to many people....

Hmm... maybe "backwards compatability" and "dont break existing users"
*are* important after all.....

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 22 Mar 2002 10:26:08 -0600

[cc trimmed]

> authority to make sure that the software at ietf.org is able to deal.

WRT to your comments in particular, I agree that SMTP has the most
difficulties. However, as stated, if something cannot be extended it can
still be replaced. And in the meantime, IDNA should be there as a fallback
position for these kinds of protocols.

I mean, considering all of the problems that SMTP has -- sender forgeries,
relay forgeries, lack of end-to-end integrity, and of course a lack of
support for i18n email addresses -- it seems likely to be a candidate for
replacement for other reasons anyway. That doesn't mean that the IDN tail
should wag SMTP, but if SMTP cannot be upgraded, well, add that to the
list of other things that SMTP doesn't do very well. In this regard, the
IDN issue is just one of many that need to be considered (i18n mailbox
names being another).

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Mar 2002 17:20:24 -0000

[email-masked] writes:
> you could *NOT* trust that all the systems
> between here and there were 8-bit-clean

I'm not saying that Quoted-Printable had no short-term benefits for its
short-term costs. I'm saying that, viewed from our long-term perspective
eleven years later, the failure to require 8-bit transparency was an
amazingly stupid decision.

If Keith Moore, Dave Crocker, Paul Vixie, et al. hadn't been so blind,
they would have required 8-bit transparency for the long term, and then
evaluated the costs and benefits of short-term 7-bit kludges in that
framework.

Probably the result would have been long-term 8-bit with no short-term
kludges. Conceivably it would have been long-term 8-bit plus optional
short-term Quoted-Printable. Either way, it would have been vastly
better than what actually happened.

Do you want to be having this discussion again in twenty years, with
8-bit problems still not fixed?

> there were a *LARGE* number of systems that broke badly if they
> were handed 8 bit data.

Let's look at the facts. John Klensin claimed in an ietf-smtp message
dated 26 Feb 91 08:40:04-EST that there were mail servers ``not robust
against that particular form of misbehavior.'' Robert Ullmann publicly
asked for proof of this claim. Klensin dodged the question.

Similarly, Keith Moore claimed in a comp.mail.mime message, message ID
[email-masked], that ``core-dumping was a
commonly observed failure mode in the early 1990s.'' I publicly asked
for proof of this claim. Moore dodged the question.

Mail servers discarding characters? Yes. Mail servers stripping the 8th
bit? Yes. Mail servers crashing? Not a single shred of evidence.

Similarly, expanding from mail to all protocols: Rick Wesson claimed in
an IDN WG message dated Sun, 24 Dec 2000 16:44:39 -0800 that ``there is
a lot of embedded systems out there that would crash-and-burn if they
received a reply in utf8.'' I asked for proof:

   Can you please identify the systems, explain how they use domain
   names, and say what exactly you mean by ``crash-and-burn''? We need
   this information if we're going to accurately assess the cost of
   upgrading the world to support IDNs.

Naturally, Wesson dodged the question.

I will readily agree that there has been an unverified report of a UTF-8
crash of an obsolete version of the Netscape mailer under Solaris. If
that report is accurate then those users will have to upgrade.

> BIND, which by default restricts it
  [ ... ]
> Why does it get restricted?
  [ bogus rationalization snipped ]

The actual history, as I mentioned in another message, is as follows.

People discovered several years ago that sendmail would blindly feed DNS
PTR results to the shell, so attackers could take over the computer by
putting some special characters, such as |<>, into PTR records. The BIND
people panicked and disabled all non-letter-digit-hyphen characters at
every spot they could think of in their DNS client library.

This isn't an 8-bit issue; it does just as much damage to underscores.

> From: Valdis Kl=?iso8859-4?Q?=BA?=tnieks <[email-masked]>

Wow. How do you pronounce that? ``Hi, I'm Valdis Klee-kwals-question-
mark-iso-eighty-eight-fifty-nine-dash-four-question-mark-kyoo-question-
mark-equals-bah-question-mark-equal-stun-ieks''? Have you considered
changing your name?

In all seriousness: Wouldn't you like to see a world where the same
character encoding is used for the name and the address and the message
body and so on, so that simple copying doesn't screw up the display?

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Thu, 21 Mar 2002 18:22:40 -0500

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Edmon Chung" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 21, 2002 5:32 PM
Subject: [idn] Re: Moving Towards UTF8 vs ASCII(ACE) Forever

> the rate at which IDNs can be deployed.
I totally disagree with this, how can the deployment of IDNA speed up the
rate of IDN deployment, given that IDNA has to upgrade all client
applications or OS with a plug-in and deploying server-side solution for
example at one ISP, or TLD will serve users in the 1000s.

> else to adopt IDNs before he can use them.

That's why without a hybrid approach, IDN will never work. Especially IDNA,
it has leakage(user cares because the ACE name is not the name they want to
pay for!!), requires a plug-in, or future change in the application(which
means not working nowadays even if we decide to deploy this).

My own thinking is that the R&D effort of adding the ACE conversion to
future applications is the same as making protocol change in future
application. However, if you look at the transitional stage, using IDNA MUST
require a plug-in, using a hybrid system will make the transition smoother,
where most of the existing system works without plug-in and if future
applications sends out new protocol will work as well.

If you look at this as a simple math equation of what you get now and what
you get in the future:
Methods               Now                     Future
ACE+IDNA         ~(x/100M)%         100%
Hybrid                  ~95%*                  100%
(where x is the number of net user willing to install client plug-in, and
roughly around 100M net users nowadays)
*(from our official test results)

At least you can get an average of  (100+95)/2% throughout the deployment
for Hybrid Systems, whereas using ACE in order to achieve the same result,
can anyone of you tell me what x needs to be: 95M!! I thought we are
engineers and scientists and this should be obvious enough and scientific
enough to prove why we need a hybrid system to make the deployment of IDN
more smooth(and Think for the users!!).

David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Mar 2002 13:08:49 -0500

> IDN issue is just one of many that need to be considered (i18n mailbox

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.  

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.

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

Keith

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 22 Mar 2002 13:12:29 -0600

> forgeries and have it provide end-to-end integrity.  so far, nobody

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.

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

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

---

From: [email-masked]
Date: Fri, 22 Mar 2002 16:06:25 -0500

On Fri, 22 Mar 2002 16:03:15 EST, "David Leung (Neteka Inc.)" said:

> 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

Which works well until you want to send a note to people in both groups,
and somebody hits "reply all".
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: [email-masked]
Date: Fri, 22 Mar 2002 16:38:19 -0500

On Fri, 22 Mar 2002 16:24:29 EST, "David Leung (Neteka Inc.)" said:
> That's right "Reply All" means the email program will "Reply All" for you,
> so why do you need to type the i18n email address by yourself with your
> keyboard!! : )

I don't need to *type* the Chinese address.

But if my MUA and MTA can't even *find* the Chinese address, that causes
much Very Bad JuJu.

> BTW, I am always seeing your email as an attachment... is this the same for
> other in the mailing list? If so Valdis can you please fix the way how you
> send out email first : >

RFC2440.  It's even a Proposed Standard.  If it's causing interoperability
problems, something probably needs to be done.  I suspect if the *main*
text/plain is being flagged as an attachment, your MUA doesn't have even
minimal support for RFC1847 multipart/signed and is downgrading to
multipart/mixed.

---

From: John C Klensin <[email-masked]>
Date: Sat, 23 Mar 2002 13:14:11 -0500

--On Saturday, 23 March, 2002 09:10 -0500 tedd
<[email-masked]> wrote:

>> BTW, I am always seeing your email as an attachment... is
>> this the same for other in the mailing list? If so Valdis can
>> you please fix the way how you send out email first : >
>> 
>> David Leung
>> Chief Technology Officer
>> Neteka Inc.
>>...
> David:
> 
> What you are receiving from Valdis Kletnieks is a PGP
> signature block (see below). Some people don't realize that
> their email appears on the receiving-end as attachments. For
> example, from just this morning email, I have three unknown
> documents (Untitled, Untitled 1, Untitled 2) on my computer
> that I have to delete from this exchange.
> 
> I would like to know how to stop this, but I am sure in doing
> so, I would also be forced to stop all attachments -- which I
> don't want.

Tedd (and others),

"Stopping this" is actually very easy (at least in principle)
and involves four steps:

(i) You get yourself a MIME-competent mail reader.  Readers and
systems that break a multipart message into a bunch of files and
spread them across your system (without an easy way to deal with
them as a single message entity) are actually no more
MIME-competent than ones that don't recognize MIME headers and
structure at all.

(ii) You install it.

(iii) You stop trying to read or process mail with software that
has not been upgraded to conform to decade-old standards and
conventions.

(iv) You spend a bit of time contemplating this experience any
time someone tells you (or you tell someone else) how rapidly a
change in the interpretation of a string or format or protocol
option will be propagated across the network.  You also spend
some additional time contemplating how much such un-upgraded
software will confuse users when it does
seemingly-incomprehensible things without explanation.  And, if
external constraints on your system environment don't permit you
to install an upgraded mail system, you contemplate what _that_
means relative to dissemination of changed/upgraded software if
a WG assumes that will happen.

The fourth is recommended even for those who have already gotten
past the first three stages.

    john

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Fri, 22 Mar 2002 15:23:12 -0500

> IDN issue is just one of many that need to be considered (i18n mailbox
I agree that IDNA should be there as transition to protocol like SMTP,
however if IDN is going to be used on other protocols like SMTP, etc...
these protocol has to be changed according to the long-term strategy for
IDN, so we should look at IDN as the root for all the other problems and
solve it first, in terms of using ACE or UTF8 for long-term, then we can
have a clear picture of how to upgrade the other protocols, eg: for SMTP we
can add extra ESMTP syntax that can handles both i18n mailboxs as ACE or
UTF8.

David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Fri, 22 Mar 2002 15:46:00 -0500

> This isn't an 8-bit issue; it does just as much damage to underscores.

I totally agree on what DJ Bernstein said, I have been look for proofs
everywhere to see how 8bit characters can "crash-and-burn" things, but wasnt
sucessful in finding any proof.

Core-dumping is the result of bad software design, and not from 8bit chars,
if you claims that 8bit chars will crash certain software, why? because you
haven't allocate enough memory for the variables that will be fed with
8bits, but I cannot find a variable type that represents 7bits and 8bits
differently, char? short? maybe on some VERY VERY LEGACY system there
maybe?!

If attackers found ways of using 8bits to crash systems or gain control of
systems, that is usual because hackers and attackers exploit security holes
in softwares, and it should be considered as a security hole and not an IDN
problem!! Moreover it should be the issues of FBI and the law enforcers and
not the issues of using IDN as 8bit or not...;>

> body and so on, so that simple copying doesn't screw up the display?

100% agree why can't we use 8bits with new ESMTP commands and MIME header
that retains the names as is!!

David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Fri, 22 Mar 2002 16:03:15 -0500

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

> 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

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Fri, 22 Mar 2002 16:24:29 -0500

David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com
----- Original Message -----
From: <[email-masked]>
To: "David Leung (Neteka Inc.)" <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>; "Keith Moore" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, March 22, 2002 4:06 PM
Subject: Re: [idn] Re: 7 bits forever!

---

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Fri, 22 Mar 2002 17:06:27 -0500

>But if my MUA and MTA can't even *find* the Chinese address, that causes

Well I thought I was talking about the needs of user to user their KEYBOARD
to TYPE in i18n email, and not the MUA or MTA being able to send or
transport the mail properly to the designate mailbox...
I though this discussion was started because some one said there will be a
need for users to have "KEYBOARDS" capable to type in all languages in order
to use i18n email, and I never said all MUA and MTA can transport or deliver
those email properly, if you see my other posting on this list you will see
that I mentioned that in order to make i18n email to work there MUST be a
protocol change on SMTP and also MIME header changes... I never said that
all MUA and MTA in the world will MAGICALLY work :>

>minimal support for RFC1847 multipart/signed and is downgrading to

The MUA that I am using is just Outlook... I dont need to built my own MUA
to read email : )

David Leung
Chief Technology Officer
Neteka Inc.
T: (416) 971-4302
http://w!.neteka.com

---

From: tedd <[email-masked]>
Date: Sat, 23 Mar 2002 09:10:13 -0500

David:

What you are receiving from Valdis Kletnieks is a PGP signature block
(see below). Some people don't realize that their email appears on
the receiving-end as attachments. For example, from just this morning
email, I have three unknown documents (Untitled, Untitled 1, Untitled
2) on my computer that I have to delete from this exchange.

I would like to know how to stop this, but I am sure in doing so, I
would also be forced to stop all attachments -- which I don't want.

tedd

---
-- 
http://sperling.com

---

From: David Frascone <[email-masked]>
Date: Mon, 25 Mar 2002 09:43:18 -0600

I get his messages as properly signed PGP attachments.  Seems like your
mail user agent is having trouble with it.  Might I suggest an upgrade
to a more "clueful" mail client?

Personally, I use mutt (http://www.mutt.org)

-Dave

-- 
David Frascone

       Famous last words - Don't worry, I can handle it.

---

From: [email-masked] (Claus Färber)
Date: 27 Mar 2002 14:09:00 +0200

> amazingly stupid decision.

From our present perspective, that's true. Back then, it might
have been the best solution.

Further, remember that the first MIME standards date back to 1992.
Back then, Unicode was brand-new and UTF-8 only came with the 2.0
version in 1996. Without UTF-8, you just could not even think
about using Unicode in message headers; and without Unicode, you
could not solve the charset-labelling problem. This might not seem
to be a problem in the Western world, which only uses ISO-8859-1
(with some exceptions) but it certainly was in Middle and East
Europe, the Arabic world, the Far East etc. "Just send 8bit" does
not work there because you don't know the charset.

> Probably the result would have been long-term 8-bit with no
> short-term kludges. Conceivably it would have been long-term 8-
> bit plus optional short-term Quoted-Printable. Either way, it
> would have been vastly better than what actually happened.

The "short-term kludges" are already going away. The body of
messages is now often sent in 8bit instead of qp. Some mailers
will still convert it down to quoted-printable but that does not
matter either because mailers will still have to support the
"short-term kludges" to handle old mail and mail sent by/through
systems that still need them.
But we still need the charset parameter. The movement towards UTF-
8 everywhere is quite new.

Actually, one could now write a specification that declares the
headers to be UTF-8 or an unkown leagacy 8bit charset.

Claus
-- 
------------------------ http://www.faerber.muc.de/ ------------------------
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0

---

From: [email-masked] (Claus Färber)
Date: 30 Mar 2002 16:13:00 +0200

Keith Moore <[email-masked]> schrieb/wrote:
> upgrade before IDNs can be used. [...]

This depends on your definition of "on the wire"; if you want to
IDNs to just work, you would have to put the ASCII version into
URIs, too. Users *do* care about URIs. If you put the UTF-8
version (%-escaped or maybe even unencoded according to a revision
of the URI specs) in the URI, they won't work with leagacy
software anyway (so ACE has no advantages).

Claus
--

---

From: Garrett Wollman <[email-masked]>
Date: Sat, 30 Mar 2002 17:43:04 -0500 (EST)

In article <[email-masked]> you write:

>URIs, too. Users *do* care about URIs.

...yet another reason why IDN represents a great deal of effort
directed at solving the wrong problem.

-GAWollman

-- 
Garrett A. Wollman   |
[email-masked]  |            History starts with a consonant.
Opinions not those of|
MIT, LCS, CRS, or NSA|

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Sun, 31 Mar 2002 11:31:36 -0500 (EST)

There is now a standard way to encode URIs containing arbitrary UNICODE
characters. This is described in RFC 3275 (which is currently a Draft
Standard), in Section 4.3.3.1, and in the corresponding W3C document and
has appeared in other W3C documents, for exampe XML Base.

Donald

On 30 Mar 2002, [ISO-8859-1] Claus Färber wrote:

> Date: 30 Mar 2002 16:13:00 +0200
> From: "[ISO-8859-1] Claus Färber" <[email-masked]>
> To: [email-masked]
> Subject: Re: Moving Towards UTF8 vs ASCII(ACE) Forever
>