Subject: [idn] An open letter to the IDN WG (long)

From: John C Klensin <[email-masked]>
Date: Mon, 19 Mar 2001 11:49:08 -0500

The rumor may have reached many of you by this time that I
made remarks at the ICANN meeting last week and at the
WIPO meeting last month suggesting that the work of this WG is
a dead end and/or that internationalization is hopeless.
Neither is true, although I have come to question, and reject,
some of the fundamental assumptions under which the WG has
been operating.  The issues are, I think, two parts technical
and one part philosophical --more in the epistemological sense
than the religious one-- and the most clear-cut and important
issues may be the philosophical ones.

I. Background and context

In between travels and distractions from various emergencies
I've been working on an exploration and explanation of both
sets of issues.  It doesn't reduce to sound bites, or even to
15 or 20 minute talks: the issues are quite complex and subtle
and I want to completely dissociate myself and my position
from anyone who says "well, if we just do this simple thing,
the IDN problem will be solved (or go away)".  Those notes,
which I had intended to email to the WG, are still not ready
and are, at this point, of I-D length rather than "note"
length.   But I do want to get the philosophical questions
onto the table in the hope that the WG can consider them very
carefully as it evaluates various proposals and presentations
during the coming weeks.

I do this with great fear: the IETF is traditionally lousy at
resolving philosophical debates.  The discussions tend to
produce a great deal of heat, less light than one would
expect, no clear way to make choices, and resentment about
whatever choices are ultimately made.  That shouldn't be
surprising, since, in ordinary society, definitive choices
among philosophical positions at typically made only by
essentially dictatorial mechanisms (including royal edicts and
majority votes to suppress minority positions) or by warfare.
Occasionally, it is possible to resolve such a choice by
perfect knowledge of what will happen in the future, but such
conditions are rare.

Usually, we try to avoid these choices in IETF for these obvious
reasons.   But we are, I believe at a juncture at which the
whole future of the Internet --and some of our most
deeply-held assumptions-- may be at stake, and I see little
choice but to explicitly open the debate.  You should be aware
that some of my most respected colleagues have predicted a
meltdown if I even send this note or otherwise open these
issues.  My belief is that they are wrong and that, faced with
a sufficiently important issue, the participants in this WG,
and the IETF in general, can and will respond to the challenge
with maturity, careful reasoning, and a focus on the long-term
future of the Internet.   Please don't prove me wrong. 

II.  The Issues - a summary of one view of where the WG, and
the IDN situation generally, stand.

(1) Indentifiers and words; Scripts and languages

The DNS was designed to contain identifiers in the strictest
sense: artificial or semi-artificial strings that could be
precisely bound to hosts or other resources.  It is reasonable
to impose fairly significant constraints on the form and use
of identifiers.  Indeed, the "restricted ASCII subset" rules
originally adopted for host names in the pre-DNS days are just
one such set of constraints.  If one chooses to broaden the
rules, then it is quite reasonable to talk about scripts and
WG-imposed (or UTC-imposed) restrictions on the use of those
scripts.

On the other hand, the IDN discussion and requirements have
been driven by explicit or implicit requirements for the use
of "words" and "names" -- names of people and of products, a
desire to spell one's name, or names of family members,
correctly, a desire to use strings in national or native
languages.  All of these are language issues, not script
issues, and the language implications are inevitable.

And the language issues are dominated about some facts about
human languages: They are ambiguous.  They are imprecise.
Each one has its own idiosyncracies and special rules, and
these may differ even between countries or regions in which
the same language is being used.  And people are very attached
to their languages as keynotes for their cultures -- some
group of engineers are not going to successfully change
language-use rules worldwide, no matter how convenient that
would be for computer systems.   Of course some people might
adapt and do so happily, just as some people have managed to
adapt to various contrived languages and simplified spelling
systems.   But most of the world won't, and most of those
potential converts are probably already using the Internet.

Directory solution needed

It appears to me that, because of the above, almost everyone
who has participated in the WG's work and understood its
implications has concluded that some sort of directory-based
approach (see draft-klensin-dnsrole-00.txt for an overview) is
going to be needed, sooner or later.  The philosophical
questions lie in the "sooner or later" part.  In particular...

If we are going to do a directory, is it worth modifying
the DNS first?  The answer seems less clear than it did a year
ago.  If, as seems inevitable, the DNS is going to remain a
repository of identifier, there is less argument for making it
"international" or "multilingual" than when we thought we
could make significant advances on the "multilingual" issue in
the DNS context.  And there seems to be general agreement that
even the most mild of modifications to the DNS increases
complexity and risk of breaking something.

That said, if we are going to start making modifications, the
argument has been that the ACE-based solutions are safer,
since they do not require changes to the DNS or the
applications that call it, although applications changes are
needed to make the encoded names intelligible and correctly
rendered.  But some of that argument depends on the assumption
--based largely on European and Japanese experience-- that it
will always be possible to enter and render Roman characters.
But the assumption is not true: we have strong indications
from, at least, China and parts of the Arabic-speaking world
that devices which cannot input or render Roman characters are
to be expected and that weakens, although does not eliminate,
the argument for ACE solutions.

We also have to face a question whose answer cannot be
predicted: our experience with Internet applications has been
that even 25% adequate "solutions" can prevent or delay the
deployment of real fixes forever or nearly so.  We need to
accept and understand the risk that, if we deploy a DNS-
modification approach, we will never see deployment of an
effective directory-based solution.  Perhaps worse, we might
need to wait until the problems with, and attempted
workarounds for, the DNS-based solutions cause the network to
reach the point of collapse or extreme fragmentation before we
can get to a decent solution.

So this is our dilemna.  The WG is perceived as being under
great pressure to produce _something_ immediately, if not
sooner.  While strawman design notes for a directory base --
including the outlines of referencing systems, a keyword
overlay, and discussion of how it might all be made to work
operationally and commercially-- are in progress and should be
ready for IETF review quite soon, there are many details and
no possibility for "immediately".  Producing an in-DNS
mechanism will take some of the pressure off, but risks
delaying good-quality mechanisms for multilingual (and I do
mean "multilingual") use of the Internet for a long time,
perhaps forever.  And, if those delays do occur, we can, I
think, expect to see local approaches, probably incompatible
ones, propagate to solve local problems for local users,
resulting in exactly the sort of fragmentation most of us
would like to avoid.

So, with the understanding that the hardest questions have no
technical resolution, we need to decide how to proceed and, in
particular, whether to go ahead with an identifier, DNS, and
script-based approach to solve a problem that involves words,
terminology, and natural language.

    john

---

From: Bill Manning <[email-masked]>
Date: Mon, 19 Mar 2001 09:23:53 -0800 (PST)

% So this is our dilemna.  The WG is perceived as being under
% great pressure to produce _something_ immediately, if not
% sooner.  While strawman design notes for a directory base --
% including the outlines of referencing systems, a keyword
% overlay, and discussion of how it might all be made to work
% operationally and commercially-- are in progress and should be
% ready for IETF review quite soon, there are many details and
% no possibility for "immediately".  Producing an in-DNS
% mechanism will take some of the pressure off, but risks
% delaying good-quality mechanisms for multilingual (and I do
% mean "multilingual") use of the Internet for a long time,
% perhaps forever.  And, if those delays do occur, we can, I
% think, expect to see local approaches, probably incompatible
% ones, propagate to solve local problems for local users,
% resulting in exactly the sort of fragmentation most of us
% would like to avoid.

	We can't avoid "local" optimizations. They are too easy to
	do and meet the 80% rule.  As was discussed in the bigz
	working group (circa 91), the largest single driver to a
	real directory system is encouraging the exaustion of easy
	memnonc lables (e.g. all the good names are taken) 
	Once the memnonic value of the lable is neglegible, a directory
	is a "natural" outgrowth. If we approach this with flat 
	spaces or with deep heirarchy are in some sense, cosmetic.
	The end result should be the same, a lable that a human can't
	possibly remember. In the addressing relem, IPv6 has already
	delivered. One reason I was so enthusiastic about IDN was the
	possibility that it would be a driver in reducing the memnonic 
	value of any given lable. (UTFx encoding vs ASCII) In hindsite
	this may have been short sighted.

% So, with the understanding that the hardest questions have no
% technical resolution, we need to decide how to proceed and, in
% particular, whether to go ahead with an identifier, DNS, and
% script-based approach to solve a problem that involves words,
% terminology, and natural language.

	Actually, the hardest questions have the simplest answers.
	Accepting the answer might be hard. :)
	To the extent that we can push a reduction on memnonoic value
	in lables, the sooner we will have a compelling case for 
	directory service.

% 
%     john

-- 
--bill

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Mar 2001 12:49:49 -0800

>         Actually, the hardest questions have the simplest answers.

"For every complex problem, there is a simple solution.
"And it is wrong."
         (Mencken, I believe.)

>         directory service..

When computer engineers make wishful assertions about our manipulating 
end-users toward some behavior goal, we usually discover why it is good 
that we specialized in working with machines and not people...

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

---

From: Bill Manning <[email-masked]>
Date: Mon, 19 Mar 2001 12:53:35 -0800 (PST)

% 
% At 09:23 AM 3/19/2001, Bill Manning wrote:
% >         Actually, the hardest questions have the simplest answers.
% 
% "For every complex problem, there is a simple solution.
% "And it is wrong."
%          (Mencken, I believe.)
% 
% 
% >         Accepting the answer might be hard. :)
% >         To the extent that we can push a reduction on memnonoic value
% >         in lables, the sooner we will have a compelling case for
% >         directory service..
% 
% When computer engineers make wishful assertions about our manipulating 
% end-users toward some behavior goal, we usually discover why it is good 
% that we specialized in working with machines and not people...

	So... you are agreeing with me? :)
	
% 
% d/
% 
% 
% ----------
% Dave Crocker   <mailto:[email-masked]>
% Brandenburg InternetWorking   <http://www.brandenburg.com>
% tel: +1.408.246.8253;   fax: +1.408.273.6464
% 

-- 
--bill

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Mar 2001 16:15:43 -0500

--On Monday, 19 March, 2001 12:49 -0800 Dave Crocker
<[email-masked]> wrote:

> 
> When computer engineers make wishful assertions about our
> manipulating end-users toward some behavior goal, we usually
> discover why it is good that we specialized in working with
> machines and not people...

And that, to reprise part of our conversation in Melbourne, is
why I believe a "grandmother test" needs to be applied to this
work.  And Nameprep --and, more generally, the attempt to get
words in free text to act as identifiers-- fails it.  Of course,
systems based on "all of us who care know what language and
coding those bits represent and can therefore interpret them
appropriately" fail even worse (although perhaps less obviously
and with fewer funny stories).

     john

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Mar 2001 13:37:36 -0800

>         So... you are agreeing with me? :)

only if you know of a way to "push reduction on mnemonic value in labels" 
that does not involve humans...

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Mar 2001 13:59:34 -0800

At 01:15 PM 3/19/2001, John C Klensin wrote:
> > When computer engineers make wishful assertions about our...
>
>words in free text to act as identifiers-- fails it.

you have perfectly telescoped the topic I was most concerned about in your 
own open letter:

         your note introduces feature creep

"The attempt to get words in free text to act as identifiers" is not a goal 
or requirement of the DNS.

It is therefore not a goal or requirement of internationalizing the DNS.

I fully appreciate the appeal and benefit with that goal, but it is not 
within scope.

Domain names sometimes seduce people into thinking that they represent 
words if free text, but that is not what they are.

         ***  And we have no need to expand domain names to be words in 
free text  ***

It is one thing to deal with a "coding" limitation and fix it, that is, to 
move from ASCII as the end-user string to an international range of 
characters.  It is an entirely different thing to try to change the 
philosophy and semantics of the domain name "type".

Even grandmothers can learn cryptic syntax, though it is not reasonable to 
force them to learn different character sets.

There is always a balance to seek and, yes, we need to be very careful 
about the burden we place on grandmothers.  However they learn postal codes 
and telephone numbers.  And all the evidence is that they learn URLs 
reasonably well.  Domain name restrictions fall well within that scope of 
restrictions.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 19 Mar 2001 14:09:32 -0800

John C Klensin wrote:

> would be for computer systems.

Isn't this the case for directories as well? Would a structured directory
solve this problem (whatever it is) better than a structured lookup? I
mean, by this argument the end-goal is unstructured, free-form meta-data
about a person, place or entity. And even then we would need structure in
order to make sense of the data (hair: brown, eyes: brown, area: X-Y).

Stepping back a bit, I think historically that we have seen people will
abide by rules and mechs which (A) address their needs in the networking
space, and (B) which are workable towards the objective of A. To wit,
nobody likes the current DNS naming system but everybody uses it anyway
because it facilitates networking and connectivity. As long as whatever
solution emerges actually works to facilitate better networking among the
Internet's users then they will adopt it. They will complain (no matter
what) but they will use it as long as it addresses some pressing need and
it works well enough.

Cumulatively, to me this means that DNS and some directory approach are
equally problematic and viable. We can argue as to whether one of them has
more long-term functionality and promise than the other (I am in the
directory camp on that one) but for solving some given problem I don't
think directories are "the default" better choice.

Furthermore, I'm just not convinced that DNS can't be made to work.
However, I am convinced that people will not embrace directories until
there is significant value from doing so (apps that use it *AND* data
stored in it).

Of course, the latter is the tricky part. Not only is it chicken-and-egg
problem, but it also opens up a HUGE political can. People who see it as
being DNSv2 will jump on it with all their mass, and it will become
immobilized. There are some ways around this problem (I have a couple of
ideas but I don't know where to take them), but just outright designating
directories as "DNSv2" would be fatal to the effort.

For all of these reasons, I think it is better to extend DNS as best as
possible. We can build up the directory architecture in the background.
Once there is enough value in the directory people should be able to
switch over to it without changing anything (or at the most will change
some workflow habits). In the meantime, DNS should be extended.

Overview:

   current DNS (no international capabilities, no directory functions)
   internationalized DNS (but still no directory functions)
   directory (with features)

The people that want the features will move to the directory model when it
is operational and has valuable services associated with it.

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

---

From: Bill Manning <[email-masked]>
Date: Mon, 19 Mar 2001 14:17:50 -0800 (PST)

% 
% At 12:53 PM 3/19/2001, Bill Manning wrote:
% >% >         To the extent that we can push a reduction on memnonoic value
% >% >         in lables, the sooner we will have a compelling case for
% >% >         directory service..
% >%
% >% When computer engineers make wishful assertions about our manipulating
% >% end-users toward some behavior goal, we usually discover why it is good
% >% that we specialized in working with machines and not people...
% >
% >         So... you are agreeing with me? :)
% 
% only if you know of a way to "push reduction on mnemonic value in labels" 
% that does not involve humans...
% 
% d/

	then I guess we disagree. :(	
	still, if we come up with a scheme, (like IPv6) that increases
	the lablesize (an alternate, on the wire encoding comes to mind)
	such that a direct (emacs) manipulation is highly undesirable,
	then I think we are on the path that leads to technology drivers
	to change humans behaviour/expectation/perceptions on what is 
	possible/doable.

	IPv4:	192.168.32.10
	I can remember this.

	IPv6:	3ffe:0805:0021:dd87:0224:8bba:feeb:daed
	This is harder to remember.

	ASCII lable: 	isi.edu
	I can remember this.

	UTF8 label:	06.60.35.55.fe.ff.a6.cc.24.24.91.33
	This is harder to remember.

	and a directory gives me the ability to search (sonex) to resolve
	abiguities.  Adding such capabilites to the DNS is non-trivial.

	To be clear, I think we need a directory service and we've needed
	it for some time.  We've already added lots of stuff that is forcing 
	the DNS into the relem of "no human serviceable parts inside" 
	(try to hand-configure SIG/KEY/NXT records for even a small zone). 
	At that point we might as well have a directory service as our
	"window" to the DNS internals.

	But I digress. I'll shut up now and let the group get back
	to IDN wg charter issues. If you want to rant on this topic
	please lets do it offline.

-- 
--bill

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Dec 1969 21:01:50 -0600

At 18.17 -0600 01-03-19, Dave Crocker wrote:
>>         it for some time.
>about 25 years.  but it has nothing to do with the current 
>requirement, unless one distorts the requirement.

I think two things are mixed up here:

(a) People seem to want to be able to use non-ascii characters in the 
identifiers we store in DNS.

(b) People see to want to store words in DNS, and not use a 
directory, and they forget that DNS is used for identifiers and not 
words.

It is very hard to fulfil these two things, because it might be that 
people want to do (a) above because of (b), and not because they 
really need non-ascii characters in the identifiers.

    paf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Mar 2001 18:17:07 -0600

At 02:17 PM 3/19/2001, Bill Manning wrote:
>...

you are more generous than I.  for the general population, they are 
impossible to remember.

however the goal for the ugly, ascii-encoded non-ascii strings is not for 
people to use them directly.  it is for an ascii-based dns server to hold 
them.  the fact that an ascii USER can obtain and look at this ugly string 
does not mean that that user is the target.

The target is the user that is using the source character set.  for THEM, 
the domain string will just as spiffy as we ascii-lovers currently enjoy.

>         To be clear, I think we need a directory service and we've needed

about 25 years.  but it has nothing to do with the current requirement, 
unless one distorts the requirement.

>We've already added lots of stuff that is forcing

huh?

>         "window" to the DNS internals.

A directory service is a wonderful idea.  Has been for 25 years.  It will 
be great when someone defines and deploys it and people start using it.

Putting it in critical path is a mistake, given that we've been waiting 25 
years.

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Mar 2001 10:23:02 -0500

John,

My favorite "grandmother story" comes from Karen Buller, who heads
NITI (National Intian Telecommunications Institute). Her (possibly
appocraphal) GM obtained dial-tone by taking scissors to the local
reservation-transiting loop until the carrier offered dial-tone to
reservation residents -- pinking shears as a backhoe. I'd like not
to take up anyone's time, my own included, on off-topic stories.

I want to use some of the values in the ranges:

                U+0000 ... U+007F

and
                U+0080 ... U+00FF

and
                U+1400 ... U+1676

I'd like "to be able to use non-ascii characters in the identifiers we
store in DNS." (Thanks to PAF for the cut-and-paste).

I don't see how changing the problem statement to languages, scripts,
and terminal fuzziness is usful. I probably slept through that bit.

The Race-to-ACE has concerned me. I'm unconvinced that the alternative
is some interposed-<Insert-Alvestrad-Mumble-Here>, your conclusion.

Sorry I can't stay to hear the CNNIC (GBK|Big5)/utf8 implementation
report tomorrow. I wish the co-chairs had placed this technical report
before the non-technical meta-*-ness.

Eric

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 20 Mar 2001 19:28:04 +0000

It has occurred to me that nameprep is currently moving two distinct
tasks from the DNS servers to the applications, when perhaps only one of
those tasks should move.  The two tasks are:

 1) Finding equivalences, for example, ABC.com == abc.com.
 2) Prohibiting some names, like a+b.com.

Currently, most applications do neither.  For example, ping is happy
to send all three of those names, exactly as shown, to the DNS server.
The DNS server performs canonicalization on each lookup, and performs
prohibition when it loads the zone file.

Both tasks become more expensive for IDNs.  Since canonicalization must
be done on each query, it makes sense to move it to the application.
But since prohibition is done rarely, I think it should remain the
job of the DNS server.  That way, if more characters are added to the
allowed set, it is not necessary to upgrade applications, but only to
upgrade the DNS servers, and it's only the servers for domains that
wish to register names containing the new characters that need to be
upgraded.

With this model, a conservative set of allowed characters could
initially be specified, because it would not be costly to allow more
characters later.

AMC

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Wed, 21 Mar 2001 15:50:12 -0600

| I think two things are mixed up here:
| 
| (a) People seem to want to be able to use non-ascii characters in the 
| identifiers we store in DNS.
| 
| (b) People see to want to store words in DNS, and not use a 
| directory, and they forget that DNS is used for identifiers and not 
| words.
| 
| It is very hard to fulfil these two things, because it might be that 
| people want to do (a) above because of (b), and not because they 
| really need non-ascii characters in the identifiers.

  After hearing the CNNIC presentation at today's WG session, I 
think that this analysis is correct and that John is indeed 
conjoining two issues that should be 'pried apart'.

  The CNNIC folks are struggling with how to make a 'usable
DNS' for Chinese speakers who are struggling with the results of
the Simplified vs. Traditional Chinese script problem.  However
I think that their definition of 'usable' exceeds the mandate of
the IDN WG, and even the DNS in general.

  While the ambiguities between the spoken and written form of
a particular language (and the interaction with the written
form being used as an identifier in the DNS) may be perhaps
worse with TC/SC, these are not problems unique to those
languages and scripts.  If I type in 'www.pain.com' into 
my web browser I might be looking for something about
French Bread or advice on managing migraine headaches.  The
fact that I get information on the latter and not the
former isn't the fault or even the job of the DNS.  Human
language is rife with homophones, cognates (both true
and false), differences in spelling, and other complex 
ambiguities.

  This is why things like search engines and web directories
and portals are so widely-used, and this area of great 
interest to folks involved in NLP and AI.  None of that
belongs in the DNS.

  Paul pointed out that this problem should not be characterized
as an Asian language problem, which I think should be
underscored.  In this respect the DNS 'disadvantages' users
of all scripts equally. :-)

  I think that these are all valid and important concerns
and point to the need for further work in this area.  Indeed
I hope that the BoF on Internationalized Keywords and
Directories tomorrow can form the nucleus for starting that
work.

  One of the things John has said repeatedly is that if we
approach this as a 'two phase' solution (where the Universal
Directory System is phase two) that we'll never get there.
While I do defer to the hard wisdom gained by John and others,
I have to think that this view is entirely too pessimistic.  
We've successfully deployed new services on the network before.  
If a new service sufficiently meets the needs of the user
community, then it has a high likelihood of being deployed
and being 'successful'.

  I realize that John's concerns also involve the increasing
complexity of the network, both in terms of its scale and
implementation, number of interacting elements, and the 
fuzzier problems of the humans who use the thing.  Our 
intuitive models on how to approach problems don't do well
in these contexts.

  At some level this is about managing user expectations.  One
of the jobs of the IETF should be to work with the user 
community to ensure that it is understood what problem a
particular piece of technical work is intended to solve.  If
the user community rejects IDN because it doesn't provide
the answer to Life, the Universe, and Everything, then
we've not done a good enough job of educating the user
community on what it is we're doing.

  Indeed John has the privilege and responsibility of
being one of those educators.  In his work with ICANN
and other organizations perhaps he could focus on fostering
the understanding in the user community on these issues.

  Best,

  -bws

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 21 Mar 2001 18:06:15 -0500

Brian,

I arrived at a different impression, but after speaking with XiaoDong Lee,
Wang Yan Feng, Sun Guo Nian, and Deng Xiang for a little over two hours 
Monday afternoon, and an additional hour (with Paul Hoffman) on Tuesday
afternoon.

My impression was that problem presented by "the Simplified vs. Traditional
Chinese script problem" was secondary, and resolvable (pun intended) by
both policy mechanisms (at registRIEs and/or at registRARs, and which is
incidently a use-case to discuss in the PROVREG WG motivating instances
of communication initiated by registRIEs and not by registANTs or registRARs),
and operationally (a form of "A record punning"). I expect Paul can offer his
recollection of this particular issue as well, as this was the very subject
we disussed Tuesday prior to the PROVREG WG meeting.

The primary motivational concern I came away from meeting with the CNNICers
was use of _any_ code points supporting some form of Chinese characters, and
that disambiguation (your "struggling with how to" comment) was a matter of
convenience, not necessity.

To put this in the specific context offered by Patrik, I've the impression
that CNNIC wants primarily to (a) "use non-ascii characters in the identifiers
we store in DNS", and only secondarily a goal only approximated by the sense
of Patrik's (b) "to store words in DNS."

Just to be sure we understand Mssrs Lee, Geng, Nian, and Xiang work, could
you explain why they presented a (GBK|Big5)/utf-8 implementation experience
report, if their interest was something other than encoding issues?

Cheers,
Eric

---

From: Jonathan Rosenne <[email-masked]>
Date: Thu, 22 Mar 2001 07:23:59 +0300

I suggest this should be phrased positively:

People seem to want to be able to use the characters of their own language in
the identifiers we use for DNS.

I'm not sure people really care how these identifiers are stored or processed,
they just want to use the script they know, rather than learn a foreign script.

And when they use their script, they want the system to take care of
representation problems, so that if they see a host name in their script in an
advertisement on the side of a bus they don't have to worry about coding issues
such as half width, precomposed etc.

Jony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Brian W. Spolarich
> Sent: Wednesday, March 21, 2001 11:50 PM
> To: Patrik Faltstrom
> Cc: [email-masked]
> Subject: RE: [idn] An open letter to the IDN WG (long)
>
>
>

---

From: "Edmon" <[email-masked]>
Date: Thu, 22 Mar 2001 07:58:23 -0500

> report, if their interest was something other than encoding issues?
Correct me if I am wrong but I think that one of the main theme of CNNIC's
presentation I think is that it also explain the distaste for ACE and the
importance of local encoding support for the transitory solution.  I believe
that failure to cater to this might cause eager implementers to sway away
from the proposed standard, at least in the transitory period.
Edmon

> Eric

Shop online without a credit card
http://www.rocketcash.com
RocketCash, a NetZero subsidiary

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 22 Mar 2001 09:19:49 -0500

Edmon,

"distaste for ACE" is pleasing to the Anglophone ear, however I believe
the CNNIC concern (and here I must rely upon a reading of a version of
their slides which was earlier than those presented yesterday, and which
I assume you saw, and of course some three hours of technical discussion
with the CNNIC team) with ASCII Compatible Encoding schemes was not just
an aesthetic preference.

Causastion and psychology of "eager implementers", or any propensity to
"sway" towards or away from "the proposed standard" are not in-scope.

Finding what is expected to work and what actually doesn't work, are.

Discussion of the former is depricated, discussion of the latter is not.

Cheers,
Eric

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 22 Mar 2001 11:02:21 -0600

>Directories tomorrow can form the nucleus for starting that

Let me emphasize:

   There is _NO_ BOF on Internationalized Keywords today (thursday).

The process of the IETF is clearly specified, and any even remotely 
related activity which causes confusion in the market will be seen as 
a denial of service attack of the IETF itself.

    Patrik

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Thu, 22 Mar 2001 11:25:47 -0600

| Let me emphasize:
| 
|    There is _NO_ BOF on Internationalized Keywords today (thursday).
| 
| The process of the IETF is clearly specified, and any even remotely 
| related activity which causes confusion in the market will be seen as 
| a denial of service attack of the IETF itself.

  My apologies.

  s/BoF/informal MINC meeting/g

  -bws

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 22 Mar 2001 22:05:02 +0000

Edmon <[email-masked]> wrote:

> I think that one of the main theme of CNNIC's presentation I think is
> that it also explain the distaste for ACE and the importance of local
> encoding support for the transitory solution.

If a DNS server chooses to automagically support queries in a variety
of encodings, then it may as well include ACE in the set of supported
encodings.  This way, IDN-aware applications, which send ACE queries,
will work anywhere, and IDN-unaware applications might still work if
they happen to be using one of these magic name servers.

AMC

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 22 Mar 2001 18:15:25 -0500

Jonathan,

If we were discussing standardizing the Korn Shell (or any other command
line interface for which 101-key keyboard input was the prevailing form
of I/O), and at some point in time some of "us" standards body participants
started working on standardizing a GUI's layout, that would be moderately
distracting. What would be awkward-or-beyond is if the GUI-concerned were
not sufficiently self-aware to disambiguate the activity they adopted, from
the activity they were, and presumably the rest of us still are engaged in.

A more useful, though perhaps not as positive a rephrase, is that attempts
to transform an identifier scheme into an opportunistic non-universal, or
into a universal, linear glyphic scripting substrate, capable of supporting
directory operations or regular (and fully i18n!!!) expressions or fonting
or fuzzy meaning is a task several linguistic bodies have shown a longer,
and brighter light upon than the majority of the IETF.

Grandmothers, apocryphal and aboard trollys garnished with enigmatic hoardings
in arcane scripts, possibly Klingon (Old High Archaic form, naturally), are
not authoring the requirements spec(s), and I wish they'd stop attending the
IETF and move over to Adobe FrameMaker or Microsoft Word or Direct Marketing
Association or Internat Advertising Bureau mailing lists, or if intellectually
inclined, to any of a number of linguistic or typographic association mailing
lists.

Now, could you offer to host a _seperate_ mailing list for people keen to
work on system representation problems? That would be positive.

Cheers,
Eric 	(member, SSILA, www.ssila.org, 
	 ex-member, DMA, www.the-dma.org, aka "Direct Marketing Association",
	 ex-member, IAB, www.iab.net, aka "Internet Advertising Bureau")

P.S. There are two (2) entities using the 3-letter-acronym "IAB". They should
     never have overlapping memberships, especially not now, though there is
     no reason why both can't be simultaniously represented in ICANN.