Subject: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

From: John C Klensin <[email-masked]>
Date: Tue, 11 Jun 2002 09:59:36 -0400

The first of my four separated issues was: 

	Is IDNA properly and adequately specified for the uses to
	which it will be put and is it designed appropriately
	for that range of uses?

One thing that Dave and I (among many others) have generally
agreed on over the years is that the primary goal of IETF
specification work is to enable and promote interoperability.
Without interoperability, we have nothing.  So a different
version of the above question is "is the IDNA specification,
including all normatively referenced and referencing documents
in addition to draft-ietf-idna-09, sufficient to enable
interoperability, or are additional or different specifications
needed".

I think the answer is probably that more specification, tightly
bound to IDNA, is needed.  In terms of the sequencing of things,
I believe that the beginning of serious work on those
specifications will expose specification problems with the
current IDNA spec.  To the degree to which that is true (and I
give some examples below), I believe that IETF procedures and
precedents dictate that IDNA should either be published as
Experimental or held as an I-D until there is adequate proof of
concept that the specification meets the needs of at least a
sample of the standards that will utilize it.

Examples of issues with the specification (few, if any, of these
are issues with the protocol):

(i) The specification now appears to say that applications can
decide to use IDNA or not.  Presumably, they can decide to use
something else instead.  It is also not clear whether "an
application", as used in the spec, refers to a standard protocol
and expectations about how all conforming implementations will
behave or to particular implementations and implementation
choices.   That is not how to get interoperability, since a
reading/receiving application will have no idea how to interpret
a string it receives.   And "receives" is key: if an
implementation issues a query in a form that appears to be an
ACE, it presumably knows what it intends, although there may be
"cut and paste" scenarios to the contrary.   But, if an
application does a DNS lookup for an LDH name (with no prefix)
with, say, an MX Qtype, and some of the result data are returned
with IDNA-appearing prefixes, then the application needs
additional clues as to how to present error messages to the
user, how to continue processing in other areas, etc.  While it
is not necessary (or possible) for the IDNA specification to
detail how it is used by all applications, setting traps for
applications without advice as to how they can be avoided does
not seem to me to be acceptable -- or promoting of
interoperability.

(ii) The specification seems inconsistent about what it about
and who needs to understand it.  It implies in several places
that it is not about the DNS and has no impact on the DNS.  But
it then makes and imposes normative DNS operational statements.
E.g., "Non-ACE labels that begin with the ACE prefix will
confuse users and SHOULD NOT be allowed in DNS zones" is
certainly a requirement about DNS and DNS zone population.

(iii) Despite the "applications can choose to do this, or not do
it" language, section 6.4 effectively implies a requirement that
any application that uses the DNS be upgraded.  That is a fairly
sweeping requirement given that we lack documents that tell
applications about other implications of doing that and that the
introductory material of the document imply that no such
recommendations will appear.  This sort of thing creates a
full-employment situation for protocol lawyers, which is
something else we usually try to avoid.

(iv) Section 7 imposes several normative requirements on name
servers and zone populations.  Again, these requirements are
buried in a document that elsewhere appears to claim that it
doesn't impact the DNS.  The third paragraph of section 7 seems
to contradict or repeal the statements of RFC 2181 that
non-ASCII strings are permitted in labels and to do so broadly
enough that it would prohibit uses favored by those who believe
that the language in 2181 is a mistake.

(v) In particular, several of the statements in the draft go
beyond almost anything we have about the DNS in trying to
narrowly constrain the behavior of RR labels and data that are
not yet defined, even in Classes that are not yet defined.  This
seems overreaching and unwise as well as confrontational with
RFC 2181 (which it, interestingly, does not cite).

(vi) I suggest that it is a useful general principle to design
service ("micro layer" to use Dave's term) protocols to be as
general as feasible without making them overly complex.  Doing
so facilitates reuse and reduces opportunities for
non-interoperability by making it explicit where variations can
occur.  It was, I believe, more or less this principle that led
to the reformulation of the nameprep/stringprep boundary.  IDNA,
by specifying nameprep profiling as part of the procedure,
violates this principle by effectively requiring a one-off
protocol for situations in which nameprep is inappropriate but
other IDNA steps would be reasonable.

My conclusions from the above are:

The IDNA specification has rolled together a collection of an
intermediate layer protocol, advice to applications, and
normative requirements on DNS use and operations (and, if a
requirement that a name server MUST NOT serve particular forms
that are permitted by RFC 1034/1035 and 2181 is intended, a DNS
protocol change).    At the same time, it handwaves about
applications adoption and does not adequately distinguish
between "application" and "implementation of an application".

Parts of it are also much broader that is required for its
purposes and are clearly beyond the scope of IDN WG competence
as a primary reviewer/approver.  The most striking example of
this is the apparent restriction to ASCII in labels and
data/parameter strings for all name servers, all RRs, and all
Classes.

It should be revised and some of that material should be pulled
out and into separate documents.  As an alternative, that
material should be highlighted: the abstract and introductory
material should indicate that these normative DNS requirements
are present, that 2181 is explicitly updated, and so on.

Finally, the apparent reach of the protocol should be narrowed
and specified, either in this document or elsewhere.  And the
protocol should recognize the reason for, and implications of,
the nameprep/stringprep split and be remodularized to permit the
IDNA _sequence_ to be used with other profiles when appropriate.
That topic is discussed in more detail in another message.

    john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Jun 2002 14:08:51 -0700

At 09:59 AM 6/11/2002 -0400, John C Klensin wrote:
>current IDNA spec.

It is certainly true that further work will develop further 
understanding.  In this business, that's a truism.

The pattern of IETF experience suggest a number of interesting guidelines, 
some of which are impressively counter-intuitive.

And intuitively obvious rule is that a complex problem needs to be studied 
carefully and thoroughly and the solution needs to be complete, before it 
is release.

The rule is wrong.

IETF experience shows that consistently, yet it is being cited here.

The rule that works -- especially for a new effort -- it to find a way to 
release the smallest, useful piece of work as quickly as possible, so that 
the learning and improving can be based on experience, rather than on 
academic introspection.

It is essential to note both words -- smallest and useful.  The former 
permits releasing something quickly, though one is hardpressed to find a 
way to apply the word quickly to IDN.  The latter ensures market pull to 
deply and use the new facility.

Infinite delay of the IDN work will have one major benefit:  The current 
proprietary solutions will gain permanent position in the market.  The 
derivative likelihood is that the IETF work will cease to matter.

We have an excellent example of this possibility with instant 
messaging.  Let's not repeat it for IDN.

>decide to use IDNA or not.

Yes, it is a meaningless statement and should be removed.  IETF standards 
are always optional.

In other words, the problem is with the presence of the statement.  The 
statement itself does not cite a meaningful problem.

>and who needs to understand it.

So the applicability text needs clarifying.  Not the normative text.  That 
is hardly a major issue.

>   It implies in several places
>that it is not about the DNS and has no impact on the DNS.

Yes, the text could be more clear.  That is often true of new 
text.  However this example of needing greater clarity again does not 
pertain to normative specification.

My own effort to work through the text suggests that the specification 
really covers 3 issues:

1.  Enhancement of the DNS label namespace, to expand to include Unicode -- 
IDN.  This is clearly a change to the formal DNS model.

2.  Provision of a general mechanism for encoding Unicode (non-Ascii) into 
a portion of the ASCII namespace -- ACE.  This requires reserving a piece 
of the existing name space.  It also requires changes to participating 
resolvers (or the software that calls resolvers) and to DNS server 
administrative tools.  However it requires no changes to the DNS protocol, 
nor to non-participating DNS entities.  Obviously it also requires changes 
to participating applications, but that is a matter concerning support for 
Unicode, rather than anything about the DNS, itself.

3.  Rules for creating internationalized host names (ie, domain names 
intended for use in URLs and email addresses) by using IDNA but still 
working under both STD13 and STD3.  For convenience, I am starting to call 
this IDNA-Host.

>any application that uses the DNS be upgraded.

If a DNS entity is going to participate in IDNA, it must be upgraded.  That 
is a truism.  Here again, the real problem is that the attempt to help 
clarify things has been counter-productive.  The right solution is simply 
to remove that bit of text.  It is not normative;.

>servers and zone populations.  ...
>
>not yet defined,

Interestingly, I believe the real problem here is with trying to do exactly 
what you are proposing, namely to work on a whole problem, rather than 
first solving the smallest, immediately useful part that can be done.  So, 
here again, the right answer is to factor out the larger work for a later 
time.  (My reading of your note suggests you might even agree on this point.)

That immediately useful work needs to be about domain names -- and more 
specifically about the strings that are used in URLS and email 
addresses.  Other domain labels that occur within DNS RRs can be considered 
in separate work.

>service ("micro layer" to use Dave's term) protocols to be as

The IDNA document's term is "shim".  I find myself preferring the 
contextual implications of that word.  Micro-layer works as a formalism, 
but shim is a term that carries more information.

>general as feasible without making them overly complex.

What generality is lacking from the current IDNA spec?

>and specified, either in this document or elsewhere.

This is amusing.

You are suggesting a bit of work that I believe is straightforward document 
cleanup, rather than substantial delay.

I agree with you.

d/

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

---

From: "James Seng" <[email-masked]>
Date: Sun, 16 Jun 2002 10:55:35 +0800

I have tried to remain silent and observe the discussion going on.

I think the discussion of IETF history, experience and best practice should
be bought to another list (poised?) or offline, despite the education value.
Given we are in the last stage of the wg, I dont think we have too many
newcomers lately.

Thanks.

-James Seng

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, June 16, 2002 5:08 AM
Subject: Re: [idn] IDNA: is the specification proper, adequate, and
complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Jun 2002 20:00:22 -0400

>Given we are in the last stage of the wg, I dont think we have too many

James,

Please review the context of the historical comment.  I was responding to 
an apparent suggestion that this working group delay publishing the current 
work until it completed additional work that had not yet started.  So, the 
reference to history was solely for suggesting guidance in the current IDN 
working group circumstance.

d/

----------

---

From: "Georg Ochsner" <[email-masked]>
Date: Sun, 16 Jun 2002 10:27:15 +0200

Dear WG,

I've been listening to you now since dec 2001. Besides all the interesting
technical aspects, I'd be very interested in the schedule now for launching
IDNs. Hundred thousands of people are actually waiting for your results and
have already spent money on IDNs. On the other side you do not seem to care
about time very much (at all?) ...

In the meantime Verisign goes its own way again and has just extended the
registration period for IDNs for additional free 4 months and will bring out
a free ACE-plug-in for IE and outlook...

My question is not technical but aiming on your project management. What is
the actual schedule? When will IDNs really go live?

Thanks
Georg

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 17 Jun 2002 08:20:59 +0900

----- Original Message ----- 
> derivative likelihood is that the IETF work will cease to matter.

At least, IETF/ICANN/DoC could issue warnings, since they sit on the top of the DNS hierarchy.
Proposing a half-baked or unimplementable soluion as standards does not help, since  
it will be abandoned  and it will be classified as yet another proprietary solution by industries
as long as everyone knows they are just quick fix for registries, not for all the public.

> messaging.  Let's not repeat it for IDN.

Seems Pointless. 
DNS is mandatory and universal, while application protocols are optional. 

If you are proposing  directory-flavored micro layer above DNS, you will get
my support. But it should  be called as an interactive translation service, instead of IDN.

Soobok Lee

---

From: "James Seng" <[email-masked]>
Date: Mon, 17 Jun 2002 08:38:46 +0800

Hi Georg,

Thanks for your note, which I believe would strike a chord with many wg
members. It is true that the group has taken far longer but the documents
are now in the hand of the IESG waiting for publication.

The best the group can do now on these documents is wait.

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Jun 2002 19:03:05 -0400

>as long as everyone knows they are just quick fix for registries, not for 

1. You are entitled to your opinion.

2. The apparent IETF rough consensus differs from your opinion, markedly.

3. Why you believe the technology is unimplementable is a matter of some 
curiosity.

4, The design principles are very far from half-baked.  In fact they are 
very well established, with extensive practical history that demonstrates 
their real, high utility.

5. Calling something from the IETF "proprietary" suggests that you also 
have a definition of proprietary that is at odds with standard industry 
nomenclature.

d/

----------

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 17 Jun 2002 13:44:41 +0900

----- Original Message ----- 

> 3. Why you believe the technology is unimplementable is a matter of some 

I18n without proper localization loses usability,interoperability and implementability.
Proposed IDN standards are not adquate for any mission critical use. This argument may be extended to
the IDN concept itself, but not up to the concept of micro-i18n-directory-layer above DNS,
which can deal more easily with approximations ,heuristic suggestion and exception handlings
about extended and open char sets.

> their real, high utility.

I have been not talking about IDNA(ACE) principle, but,
some advocates of UTF8-based solution would argue in that same way against ACE,
because UTF8 use is well established and encouraged in numorous IETF standards.
But,it's clear that even UTF8-based solutions will suffer from the same kind of
l10n and implementability problems as those of IDNA.

> have a definition of proprietary that is at odds with standard industry 

The application/OS industries and TLD registries will answer for it by actions.

---

From: "Edmon Chung" <[email-masked]>
Date: Mon, 17 Jun 2002 03:33:48 -0400

Hi Georg,

This is a very interesting question you ask.  You see, the real question is
really when will registries be moving to transition towards IDNs.  And the
answer to that question "should" be now.  The reality is that whatever IDNA
states, there will be a lengthy period for transition.  First we need to
wait for the documents to be published (which is what we are doing now),
then it is waiting for application providers (such as MSIE or NSCP) to adopt
the standard in their next release of sofware, then we wait for them to
become stable, then we need to wait for the propagation of the new versions
in the market.  And remember every single person on the internet must
upgrade their application, and it is not just the browser, but also any
application that uses domain names in any form.  All in all, it means that
if you want a meaningful percentage of internet users to be able to access
IDNs you are looking at at least a handful of years.

The answer for your concern is therefore in the transition.  How do a
registry provide a seamless transition that makes sense and create a
positive user experience?  We all know very well that users with existing
applications will attempt to access a multilingual domain name and that
these requests will reach the registry DNS server.  Whether the registry
decides to resolve the request or not is their choice.  If the registry
decides to resolve these request (even that it is not preformatted in ACE),
then IDNs are live immediately.  If not, they would most likely be inundated
with customer support calls asking why the names dont work (such as observed
by the VeriSign testbed).

So, my point is, it is up to the registries really when they decide to
address the issue.  In fact .cn and .tw has been working very hard towards
this and have successfully rolled out multilingual.cn and .tw names in their
respective countries.  So has .bz, .tv, .cc and .nu, all of the IDNs under
these domains work already in varying degrees.  And as the millions of users
start to download or upgrade those new IDN aware applications, we will
slowly but surely move towards a standard.  But the key here is the
transition and that can happen today.

Edmon

PS. I could provide you with a more extensive document outlining the issues
and challenges for a domain registry and how to address them with the right
technologies if you wish.  cause this is probably not the best forum to just
send an attachment into.

---

From: vint cerf <[email-masked]>
Date: Mon, 17 Jun 2002 06:22:14 -0400

It seems to me that we err if we mix "finding" identifiers
(with search engines, elaborate directories that offer multiple
choices of IDNs based on imprecise search criteria) with
resolving unambiguous identifiers into their respective IP addresses
(speaking roughly since DNS also offers indirect resolutions such as
MX, CNAME and so on).

I think we do ourselves a disservice if we try to make DNS resolve
ambiguous references - it is not designed for such applications;
search engines and directory structures are more oriented towards
that aspect of finding things "by name" on the Internet.

Vint

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Jun 2002 13:16:31 +0200

> that aspect of finding things "by name" on the Internet.

This seem to argue against the current design of IDNA.

IDNA resolves some ambiguities in identifiers by Unicode
normalization, and introduces further ambiguities by not handling
legacy charset transcoding issues at all.

Admittedly, "resolving ambiguities" in human entered text strings is a
fuzzy area.  One extreme is to not resolve any ambiguity at all, the
other is to use as much intelligence in the software as possible to
figure out what the user meant.  Domain names in DNS traditionally was
in the first extreme, IDNA move things slightly toward the other
extreme with normalization and legacy transcoding, but far from
approaching search engines or directories.

Now, one can argue that Unicode normalization is only used because
Unicode happens to have different ways of representing the same, or
non-visual, characters, but nevertheless this adds an ambiguity
resolving mechanism to software.  One that will have to be modified
over time, as well, since consensus on how to resolve ambiguities will
change over time.  I have trouble visualizing how this can be
implemented and work well for 2, 5, 10 years and more, when Unicode
and other charsets are moving targets.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 17 Jun 2002 08:26:35 -0700

>legacy charset transcoding issues at all.

Simon, both of those statements are wrong, and Vint is right. Unicode 
normalization doesn't fix ambiguous references, it canonicalizes 
references: there is a huge difference between those two. "Letter A 
followed by combining umlaut" is not ambiguous: it means that the 
display should show an a with an umlaut over it. There are charset 
transcoders today that transcode differently from each other. That's 
not an ambiguity, that's a mistake. No one can create protocols that 
fix every previous mistake.

>and other charsets are moving targets.

So your solution is that nothing can ever be internationalized?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Jun 2002 18:32:09 +0200

Paul Hoffman / IMC <[email-masked]> writes:

> display should show an a with an umlaut over it.

If I see the (swedish) word "å" displayed on my screen, cut'n'paste it
into a browser, an IDNA resolver will normalize this into U+00C5
before a server is queried for that string, regardless of whether the
original string was U+00C5 or U+212B.  Isn't this "resolving
ambiguity"?  Isn't there an ambiguity between U+00C5 and U+212B?  If
there isn't an ambiguity between U+00C5 and U+212B, why does IDNA
treat them the same?  Perhaps I fail to communicate, not being a
native speaker perhaps I'm interpreting the word "ambiguous"
incorrectly, although my dictionary doesn't seem to help me find any
alternative interpretation.

> There are charset transcoders today that transcode differently from
> each other. That's not an ambiguity, that's a mistake. No one can
> create protocols that fix every previous mistake.

You can fix the one mistake.  Building a critical infrastructure on
past mistakes doesn't like a good idea to me.

> So your solution is that nothing can ever be internationalized?

That's not a solution, and that's not what I'm proposing, I don't
understand how that could ever be read into what I wrote, but I'll try
to be specific on how to solve the problems with IDNA right now,
giving internationalized domain names that would be secure and could
be implemented and continue to work years ahead:

First, specify clearly that application MUST NOT use any other
normalization table than the one defined in the IDNA spec suite
(following Unicode 3.1 currently, being updated to Unicode 3.2 if I
understand things correctly) and that in particular normalization
tables supplied by operating systems should never be used unless the
application author can assert that they will never change throughout
the lifetime of the application (which probably only will be true if
the application author is the operating system author).

Secondly, define how to transcode legacy charsets into Unicode, and
specify that only this transcoding table is to be used.  Transcoding
mapping tables can be defined in RFCs, much like MIME CTE's or
similar.  The initial IDNA spec suite could define transcoding tables
for commonly used charsets; ISO-8859-X, ISO-2022-X, KOI8-X,
KS-C-5601-X etc.

The main argument against these proposals are that they require lots
of work to implement, but if the alternative is poor security, I'd
rather have people do lots of work.  A lesser argument against it is
that they don't adopt new updates to Unicode, but that is by design.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 17 Jun 2002 10:16:56 -0700

At 6:32 PM +0200 6/17/02, Simon Josefsson wrote:
>ambiguity"?

No, it is canonicalizing. In the bits on the wire, there is nothing 
ambiguous about the combined version or the uncombined version: they 
are very clearly different sets of characters, and the representation 
of those characters in every encoding of Unicode is also 
non-ambiguous.

>   Isn't there an ambiguity between U+00C5 and U+212B?

Only visually, not in the protocol.

>   If
>treat them the same?

It doesn't. It canonicalizes one into the other. That is far from 
"treating them the same", yes?

>   Perhaps I fail to communicate, not being a

My dictionary has these definitions:
- having two or more possible meanings
- doubtful, uncertain
U+00C5 and U+212B do not have the same meaning, and there is nothing 
doubtful or uncertain about either of them.

>You can fix the one mistake.

Which one mistake is that? There are probably dozens of transcoders 
with errors, and worse yet, there are probably dozens of transcoder 
implemntors that, in the face of some IETF or Unicode standard that 
tells them how to transcode, would say "screw you, you don't 
understand our language" (and they would possibly be correct).

>understand how that could ever be read into what I wrote,

Because you said "I have trouble visualizing how this can be 
implemented and work well for 2, 5, 10 years and more, when Unicode 
and other charsets are moving targets." I agree with you that Unicode 
and other charsets are moving targets.

>  but I'll try

We already say the first part (you must use the Unicode 3.1 -- soon 
to be Unicode 3.2 -- table). We don't say the second part because it 
flows from the first part.

>for commonly used charsets; ISO-8859-X, ISO-2022-X, KOI8-X,

Yes, we could do that, but the IETF lacks both the linguistic and 
political expertise to do it. The fact that even the experts such as 
ISO and the Unicode Consortium have not chosen to do this should be a 
very broad hint to you about why the IETF shouldn't. But if you 
really think this is needed (I still don't), you absolutely should 
ask the appropriate bodies (Unicode or ISO) to do it. If they do it, 
I'd bet that the IETF would strongly consider pointing to those 
standards.

>that they don't adopt new updates to Unicode, but that is by design.

We disagree about what the main argument is. Creating transcoding 
tables is easy; in fact, it has already been done. See 
<http://www.unicode.org/Public/MAPPINGS/> for some non-official 
mappings.

My main argument against the IETF doing this is that being sure the 
tables are "right" is nearly impossible because it involves getting 
consensus among the users of the scripts and the experts.

--Paul Hoffman, Director

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Jun 2002 20:17:22 +0200

Paul Hoffman / IMC <[email-masked]> writes:

> of those characters in every encoding of Unicode is also non-ambiguous.

Right.  But isn't the _reason_ for canonicalizing that the characters
are visually ambiguous?  The canonicalization step isn't there for the
fun of it, surely.  If the reason for canonicalization isn't to
resolve visual _ambiguity_, what is it there for?

> Only visually, not in the protocol.

The IDNA "protocol" handles how the visual ambiguity is resolved, with
the technique being canonicalization / normalization / decomposing.

> "treating them the same", yes?

Sorry, I don't see the difference.  After IDNA processing, strings
containing U+00C5 instead of U+212B look the same.  There is no way at
the server to tell whether the user entered U+00C5 or U+212B.  There
is no way to register two domains that only differs by the Unicode
code point for "å" chosen.  This is what I meant with IDNA treating
them the same.

Resolving ambiguity in this way can introduce ambiguity.  Consider a
user intentionally entering U+212B because it has a different meaning
than U+00C5 attached to it in Unicode, IDNA resolves this into one
code point.  Unless the user knows the Unicode 3.2 decomposition
table, it is uncertain to her whether those two code points are
treated differently or not.

> doubtful or uncertain about either of them.

If you look at the character "å" it can have at least two (Unicode)
meanings, either U+00C5 or U+212B.  This ambiguity is resolved in IDNA
by normalization.  To the user, whether "å" denotes U+00C5 or U+212B
is "ambiguous".

> understand our language" (and they would possibly be correct).

The mistake is that the transcoding tables are not specified
somewhere, for IDNA purposes.

If they tell us that, and is correct at telling us that, why not let
them define the transcoding table?  Sounds like maybe they will do a
better job.  If different people says that, you need to invite all of
them to resolve their differences, or state that IDN will not work
with charset X because people cannot agree.  IMHO the end result will
be better than (as is proposed now) leave those people alone to
implement different transcoding tables.

> and other charsets are moving targets.

"This" was referring to the current IDNA proposal.

I'm convinced it is possible to implement internationalized domain
names in a way that works. (In fact, I see IDN's on ads in buses and
trains every other week or so, to doubt that it is impossible to
implement would be foolish.)

> We already say the first part (you must use the Unicode 3.1 -- soon to
> be Unicode 3.2 -- table). We don't say the second part because it

OK, perhaps it is sufficient.  We'll see how people implement it.

> very broad hint to you about why the IETF shouldn't. But if you really
> think this is needed (I still don't), you absolutely should ask the
> appropriate bodies (Unicode or ISO) to do it. If they do it, I'd bet
> that the IETF would strongly consider pointing to those standards.
>

Perhaps we do agree, it was the consensus building I was referring to
with the "require lots of work".

Without solving transcoding issues, and if banks have the nerves of
using non-ASCII IDN's for critical purposes, people will exploit these
characteristics of IDNA.  With the current proposal, I think banks
will not chose to use IDN's because there are security concerns, which
I consider a partial failure of IDN.

I don't see much useful coming out of this discussion, and I'm not
offering to talk with ISO or Unicode, so I'll stop whining for now.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 17 Jun 2002 11:32:23 -0400

> This seem to argue against the current design of IDNA.

I don't agree.

It is an example of IDNA solving the problem of using identifiers with
non-ascii codepoints.

IDNA does _not_ (and I think that has been clear all the time from us
writing the spec) solve the problem with use of "words" with non-ascii
codepoints.

As Vint wrote, DNS is extremely bad at the functionality needed for word
matching. Issues like locale dependent matching rules, ambigous result
sets, more interactivity all are non-existing in the lookup system DNS
defines.

Regarding the "normalization for resolving ambiguities", I think we talk
about different kind of ambiguities. In the case of normalization we only
take care of the ambigous representations that, according to UTC, exists in
the design of the Unicode Character Set. If you do word matching, you get
different (often-locale-dependent) ambiguities, part from of course
context-dependent ambiguities which exists because two very different
things can be named exactly the same.

     paf

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 17 Jun 2002 21:32:36 -0700

> treated differently or not.

I don't see where the problem lies.  Yes, U+00C5 and U+212B do look
identical; the existence of pairs like this is the main reason why
canonical equivalence tables exist.  If you *could* have two separate
domain names whose only difference was that one contained U+00C5 Å and
the other contained U+212B Å, now *that* could cause spoofing problems.

> by normalization.  To the user, whether "å" denotes U+00C5 or U+212B

There aren't two meanings.  Unicode considers them to be "canonically
equivalent."  They both exist in Unicode because somewhere, once upon a
time, there was a legacy character set that included both, and Unicode
wanted to provide round-trip mappings for both.

That should be a clue that these "problems," if they are that, didn't
originate with Unicode.

> somewhere, for IDNA purposes.

IDNA deals with Unicode.  Transcoding between Unicode and other
encodings is the responsibility of client-side software that does not
natively deal with Unicode.

> I consider a partial failure of IDN.

I have to agree with Paul.  Neither the Unicode Technical Committee, nor
ISO/IEC JTC1/SC2/WG2, nor anyone else can force vendors to adopt uniform
mapping tables, or to mean the same thing when they say (for example)
"Shift-JIS."  Applications will continue to use transcoding routines
supplied by the operating system, even if Unicode or IDNA were to
publish "definitive" mapping tables.

Transcoding between 80,000 legacy encodings is what we had to do before
Unicode came along.

-Doug Ewell
 Fullerton, California