Subject: [idn] who should be doing IDN filtering

From: Eric Johanson <[email-masked]>
Date: Wed, 16 Feb 2005 19:37:31 -0800 (PST)

I've been lurking on this list for the past few days - - and it seems that 
we've been thrashing about with different filtering techniques IDN on 
various TLD/registrars, etc.  I hope this post won't prove to be a 
distraction from that dialog (as I'm one of those "don't know anything 
about unicode" folks).

My question for the group:

Are you sure that it's the registrars/TLDs/etc whom should be doing this 
filtering?

I understand that that by using the language tag, it generally might make 
some type of filtering concepts easier & more practical to deploy.

Because this 'language tag' is only available to registrars (when I say 
registrars, I mean anyone involved with the registration of a new domain, 
on any TLD), I suspect it makes it impractical to do the filtering at the 
browser/application level.

My question is:

...assuming we can make the language tag available via some dns tricks or 
some API...

Shouldn't we leave the filtering up to the user, and the user's browser? 
It's likely the application will know more about what the user expects as 
far as site identity (some tricks I've heard proposed is to not warn about 
sites in the users favorites, or create whitelists of 'trusted sites' [see 
trustbar]), and knows about the local language settings.

For example, if I have windows XP, with the default language set to 
german, the browser isn't (as obligated) to warn the user of potential IDN 
phishing attacks when it sees german scripts in the IDN. My hope is that 
this idea could scale to any script/language, but I fear that I'm missing 
something.

I'm not proposing we don't have some type of filtering of IDNs at the 
registrars, etc.  I'm simply proposing we give application (browser, 
email) developers the same information the registrars have, in order to 
give them a fighting chance of warning the user of a homograph attack.

Taking this one step further:

.. if we think about IDN homograph attacks as the same class of problem as 
'spam/UCE'....

..Then tools will just start to exist to filter it. Imagine, if you will, 
a RBL which collects IDNs found in spam/phishing attacks, and communicates 
with a users browser.

Comments/ideas/flames?

-Eric 'Dodgy Character' Johanson

---

From: Martin Duerst <[email-masked]>
Date: Thu, 17 Feb 2005 18:17:32 +0900

Hello Eric,

filtering?

Yes, this would be ideal. The main reason is that a domain name
gets registered 1 time, but it gets used thousands if not millions
of times. Also, there is much less software for registration, which
can be updated much more easily, than e.g. updating all the browsers
around the world. In addition, some approaches require tables, which
might be difficult to fit into a mobile phone.

This does not exclude that browsers would implement some warnings
in certain cases, but that may be with completely different means
(e.g. a browser could check a "phishing alert" database and put
up a warning for pajpal.com; it seems that you already had
a similar idea at the end of this mail).

Not exactly. The main reason would be that even with language tags,
different registries may have different policies.

On the other hand, except for those cases where there is a
'reservation' of variants, even the registrar/registry doesn't
have to know the lanugage except for tracking purposes. As long
as it fits any one of the tables they offer, it's okay.
And 'reservation' up to now only has been used to address the
simplified/traditional case in Chinese. While it may look nice
in theory to e.g. create some mechanism for reserving/
equating o-umlaut and oe in German, and so on, this isn't
actually appropriate for names (Goethe (the famous one) would never
be written Go"the, altough there are plenty of Germans that
write their name that way). Then there are the cases where
an 'o' and an 'e' are adjacent without being pronounced like
o-umlaut. And then the number of such letters per name is
small enough to let people register both variants if they
think they need to.

some API...

These kinds of warnings are indeed appropriate on the user side.
But the language tag isn't helpful for that; the user sees (and
is potentially fooled by) the characters, not the language tag.

No, this is an idea worth exploring. But the problem is that it
may be a lot of work to try to figure out what kinds of letters
German users confuse, and there may be a lot of variation between
different users, and browser makers may have a hard time covering
more than just a few languages.

 >I'm not proposing we don't have some type of filtering of IDNs at the 
registrars, etc.  I'm simply proposing we give application (browser, email) 
developers the same information the registrars have, in order to give them 
a fighting chance of warning the user of a homograph attack.

They have a chance already. Language information doesn't buy
them anything more, I think.

 >.. if we think about IDN homograph attacks as the same class of problem 
as 'spam/UCE'....

Feasible maybe, and if feasible, can be used for plain old ASCII stuff, too.
Or is it that because it hasn't been used for ASCII, we may conclude that
it doesn't work for IDNs?

Mind you, there are very serious organizations (e.g.
http://www.antiphishing.org/) which are very hard at work to
make sure that anybody involved in real phishing (as opposed to
setting up an example to show how you might do it) gets removed
from the DNS and the Web as quickly as they can manage.

Regards,    Martin.

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 17 Feb 2005 09:58:32 +0000

Eric Johanson <[email-masked]> wrote:

> Are you sure that it's the registrars/TLDs/etc whom should be doing
> this filtering?

I think registries should be doing filtering, but I don't think browsers
should depend on it, because it's already too late, as the paypal
example proves.  I think browsers (and in general, applications that
receive domain names from untrusted sources and display them to the user
as IDNs) ought to provide a second line of defense by trying to expose
suspicious domain names.

> Because this 'language tag' is only available to registrars (when I
> say registrars, I mean anyone involved with the registration of a
> new domain, on any TLD), I suspect it makes it impractical to do the
> filtering at the browser/application level.

I don't see why.

> ...assuming we can make the language tag available via some dns tricks or 

I don't see that happening.  The IDN working group decided quite
deliberately that domain names would not contain any meta-info like
language tags; they're just text strings.

Still, I expect that some not-terribly-complex heuristics, based only
on the bare character strings, could go a long way toward exposing
suspicious domain names.

AMC

---

From: Soobok Lee <[email-masked]>
Date: Thu, 17 Feb 2005 20:59:19 +0900

Hi, Adam !

>language tags; they're just text strings.
Yes. human transcripting or copy&paste would not coexist with such lang
tags.

>on the bare character strings, could go a long way toward exposing
suspicious names from cyrillic i and latin i can be easily compared against
in the registration stage without any huristics , only with "tables".
Yes. it would not be so terribliy complex. :-)

Soobok

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Feb 2005 11:05:33 -0500

--On Thursday, 17 February, 2005 09:58 +0000 "Adam M. Costello"
<[email-masked]> wrote:

>...
>> ...assuming we can make the language tag available via some
>> dns tricks or  some API...
> 
> I don't see that happening.  The IDN working group decided
> quite deliberately that domain names would not contain any
> meta-info like language tags; they're just text strings.

Concur.  I also concur with the several folks who have pointed
out that, at browser time, language information won't do a whole
lot of good, at least without access to every per-domain table
for the characters that are assumed to be bound to a given
browser.  

> Still, I expect that some not-terribly-complex heuristics,
> based only on the bare character strings, could go a long way
> toward exposing suspicious domain names.

I used to be convinced of this, but have become increasingly
skeptical about how far it would take us.  The easiest tests in
principle are for for homogeneity of characters within a label
(the "one label, one script" test, more or less).  Those tests
are indeed fairly simple if the label contains characters that
form a contiguous block in Unicode that conforms, more or less,
to one script.  That requires a somewhat fuzzy definition of
"script", which is probably ok, but also isn't a hugely good
test once one gets out of the low-end of the BMP and the scripts
taken over, as blocks, from prior standards.  After that, the
tests get more complex, to the point that one can imagine
needing all of the Unicode script tables (assuming they are
adequate, which they probably are for this purpose) within the
application to make a good test.  A test based on those tables
wouldn't be terribly complex computationally, but the notion of
carrying those tables around in resource-limited devices, or
even in a browser whose footprint one was trying to minimize,
gets a little dicey.

But the important question, I think, is what attacks that would
protect us against.   Certainly, it would provide protection
against a name accidentally registered with an odd mix of
characters.  But I suggest that is a null set -- if a label is
entered into the DNS with a heterogeneous collection of
characters, 
it is because someone decided to do it and the registrar and
registry decided to permit them to do it.  That isn't an
accident, that is a deliberate set of decisions, for whatever
reasons.  As the bad guys get more sophisticated, there are
going to be attacks that will be far harder to detect than
either the paypal or yah00 examples that have shown up on this
list, many of them probably involving mixtures of scripts
neither of which is Roman-based.

So, should the browsers (or other UI programs) take whatever
precautions and issue whatever warnings are reasonably feasible?
Sure.  Should we assume that will help very much against a
determined and sophisticated attacker?  Nope.  Can a lot more be
done at registration time than at lookup (or user inspection)
time?  Yes, certainly -- not only is the code base easier to
control and the "language" information available, as has been
pointed out, but taking some time on _those_ servers to look up
script tables, compare them to labels, and even apply variant or
other cross-checking rules if the domain considers that
appropriate would be perfectly rational.

I think we will find ourselves, a few years down the line, in a
situation in which users discover that names in some domains, by
virtue of tighter registration policies, will be safer to use
than others.  If that results in competitive pressures on the
more relaxed ones, so much the better.  But, in the general
case, it may be about as much as can be done.

   john

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Feb 2005 08:39:52 -0800

>as IDNs) ought to provide a second line of defense by trying to expose

I fully agree with Adam here. If there is no way to enforce 
registries doing the right thing (and ICANN has shown no ability to 
enforce nearly anything), then relying on them for security is silly. 
This is particularly true if some registries pay more attention to 
their customers who want to pay for  mixed-script domain names than 
they pay to ICANN.

>language tags; they're just text strings.

Right. If you want to re-engineer the IDN bits-on-the-wire protocol 
in ways that were considered and rejected, feel free to submit a new 
Internet Draft and see if there is community interest.

>on the bare character strings, could go a long way toward exposing

Reducing phishing is sufficient because we can never eliminate it.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Thu, 17 Feb 2005 12:53:23 -0500 (EST)

Assuming we can't cut ICANN out of the picture, isn't one solution to 
lobby ICANN to allow for new TLDs with policies that forbid misleading 
IDNs and let the marketplace sort it out?

Maybe the IETF could issue a statement of some sort on the security 
implications of failing to allow such TLDs into the marketplace?

On Thu, 17 Feb 2005, Paul Hoffman wrote:

> I fully agree with Adam here. If there is no way to enforce registries doing 
> the right thing (and ICANN has shown no ability to enforce nearly anything), 
> then relying on them for security is silly. This is particularly true if some 
> registries pay more attention to their customers who want to pay for 
> mixed-script domain names than they pay to ICANN.
>
> Right. If you want to re-engineer the IDN bits-on-the-wire protocol in ways 
> that were considered and rejected, feel free to submit a new Internet Draft 
> and see if there is community interest.
>

-- 
http://www.icannwatch.org   Personal Blog: http://www.discourse.net
A. Michael Froomkin   |    Professor of Law    |   [email-masked]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                          -->It's cool here.<--

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Feb 2005 12:40:12 -0500

--On Thursday, 17 February, 2005 12:53 -0500 "Michael Froomkin -
U.Miami School of Law" <[email-masked]> wrote:

> Assuming we can't cut ICANN out of the picture, isn't one
> solution to lobby ICANN to allow for new TLDs with policies
> that forbid misleading IDNs and let the marketplace sort it
> out?

Michael,

"Misleading?"  Why should IDNs be any different from ASCII-only
labels?  "M1CR0S0FT" would certainly be a "misleading" label
from the point of view of the obvious company, but the community
concluded, long ago, that problem should be dealt with by UDRP
procedures or court action, not having some registry make up
rules about what can't be registered based on what someone else
thinks is "misleading".

For the special case of mixed-script labels, ICANN already has
guidelines in place that requires gTLDs who choose to register
IDNs to limit any given label to a single "language" or small
set of languages.  Those guidelines are, IMO, badly written and
ambiguous and need fixing, but, as far as I know, all of gTLDs
except two are conforming to those guidelines and, in
particular, not permitting registrations of strings for which
they don't have established language tables.   The registry for
the other two has apparently decided, partially for historical
reasons, to go ahead and register almost anything that doesn't
match a language for which they already have tables... a topic
that has been discussed on this list already.

The ccTLDs which have decided to deploy IDNs and who are not
bound by those guidelines, have, by and large, adopted registry
restriction rules that are intended to prevent mixed-script and
other types of IDN-baesd misleading names when feasible.   Some
of them are based on "characters in use in our territory" and
"names we need to be able to represent in order to assure
fairness" rules, rather than strict language or script rules,
but I suggest they are still within the general intent of
preventing misleading mixed-script labels when possible.   While
policies differ, most of the ccTLDs, and an even larger majority
of those operated to support DNS use in the relevant country,
are consistent with the general spirit of the ICANN guidelines.

Some of us continue to believe, I hope consistently, that
conformance based on consensus and conclusions that it is the
Right Thing to Do is much better than trying to devise an
enforcement regime.  I know you didn't suggest an enforcement
regime, but others in this discussion have come pretty close.
And, for prohibitions on registration of mixed-script misleading
names, the worldwide conformance level, among TLDs that have
deployed IDNs, to the general principle is fairly high.

As far as the marketplace sorting this out, I suggest that the
marketplace has already spoken, without any requirement to make
up new TLDs to seek a stronger message.  We have TLDs (country
code and generic) who prohibit IDN registrations.  We have TLDs
(again, both groups) who permit IDN registrations only if
languages are identified and script rules carefully adhered to.
And we have TLDs who permit registration of almost anything
permitted by IDNA, either explicitly or through some loophole.
What I haven't seen, before or after this latest
phishing-possibility demonstration, is a single instance of an
advertisement or press release that says "you should register in
our domain rather than theirs because our permitted-label rules
are more restrictive and hence will give you and your users
better assurances that they aren't being phished".  Nor have we
seen any symptoms of registrations migrating spontaneously among
domains to reflect those concerns.   If the marketplace has any
intent of speaking to this issue --or "sorting things out"-- it
is doing so in a whisper.  

I am a little depressed by that.  I'd be much happier to see
"our domain is safer than their domain" ads and positive
responses to them, just as I would have been happy to see
"register in our domain because we promise to never try to
divert the typing mistakes of your users to your competitors" a
year or so ago.  But they don't happen.  And, using the second
case as an example, there is zero evidence that it has had any
marketplace effect on registrations.    The marketplace for
registrations just doesn't seem to care, and we don't need more
TLDs to tell us that.

> Maybe the IETF could issue a statement of some sort on the
> security implications of failing to allow such TLDs into the
> marketplace?

For the mixed-script case and some related ones, such TLDs are
already in the marketplace and are actually the large majority
of TLDs.  There is a reason why that paypal example didn't show
up in AERO, BIZ, CH, CN, DE, INFO, INT, JP, ORG, SE, TW, and a
host of others -- it could not have been registered, either
because the registry prohibits mixed-script registrations or
because it is going slowly about IDN deployment, wanting others
to get more experience first.

So what would you like the IETF to say, exactly?  "Domains that
are being cautious about registrations should advertise the fact
better"?  Not exactly an IETF-type statement.   "Guidelines that
prevent obvious abuses are good"?  The IETF has already said
essentially that -- see the "IESG Statement" on IDNs -- and most
of the TLD registries are doing it as they deploy IDNs.  Or
perhaps "200 plus domains are already proceeding safely in this
area so security requires that we add a few more who will too"?
Doesn't pass the laugh test, at least from where I sit.

best,
     john

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 10:52:55 -0800

Paul Hoffman wrote:
> If there is no way to enforce registries 
> doing the right thing (and ICANN has shown no ability to enforce nearly 
> anything), then relying on them for security is silly. This is 
> particularly true if some registries pay more attention to their 
> customers who want to pay for  mixed-script domain names than they pay 
> to ICANN.

Well, it may be that security is not just a technical issue but also, 
importantly, an economics issue:

http://www.cl.cam.ac.uk/users/rja14/econsec.html

However, based on private email with a fairly high-ranked individual at 
VeriSign, I am willing to give them the benefit of the doubt for a 
while. If they soon state on this mailing list that they intend to put 
some solution in place to combat the IDN spoofing problem, and then they 
back up their words with real actions, we're all set (at least for .com :-)

>>> ...assuming we can make the language tag available via some dns 
>>> tricks or some API...
>>
> Right. If you want to re-engineer the IDN bits-on-the-wire protocol in 
> ways that were considered and rejected, feel free to submit a new 

First, I cannot speak for Eric here, but it seems to me that "DNS 
tricks" could include having a (new?) DNS record for the language(s). 
This would not embed the language tag in the domain label itself. The 
language tag could be looked up in DNS. (However, I don't like this 
whole language business anyway, as I indicated in other emails.)

Second, with all due respect, Paul, Adam et al, stringprep and nameprep 
are 2 amazing pieces of work, but I feel they did not go far enough. I 
think it is probably worth exploring whether we might map homographs to 
"base" characters in a new "prep", perhaps another profile of 
stringprep, to combat the IDN spoofing problem.

Third, there seems to be some resistance to continuing IDN work in the 
IETF space. So, an Internet Draft may not be appropriate. Michel has 
indicated that the Unicode Consortium is working on the homograph 
problem, so maybe we can place our bets there.

Alternatively, if some registries (e.g. CJK) wish to have their own 
rules (i.e. RFC 3743 "JET"), then they can of course do so. I certainly 
do not want to have a balkanized net, but the degree of balkanization is 
what matters. I.e. if we only have 2 methods (CJK vs the rest), that's 
better than having numerous methods.

Erik

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 17 Feb 2005 11:16:50 -0800

At 10:52 AM -0800 2/17/05, Erik van der Poel wrote:
>>in ways that were considered and rejected, feel free to submit a 
>>new Internet Draft and see if there is community interest.
>
>tricks" could include having a (new?) DNS record for the 
>language(s). This would not embed the language tag in the domain 
>label itself. The language tag could be looked up in DNS. (However, 
>I don't like this whole language business anyway, as I indicated in 
>other emails.)

I will say it again: put together a fully-formed proposal. Suggesting 
anything that requires understand of the DNS beyond simple A records 
needs and Internet Draft or at least a stable web page. Few people on 
this mailing list (myself included) are facile with alternate DNS 
records and the like.

>Second, with all due respect, Paul, Adam et al, stringprep and 
>nameprep are 2 amazing pieces of work, but I feel they did not go 
>far enough. I think it is probably worth exploring whether we might 
>map homographs to "base" characters in a new "prep", perhaps another 
>profile of stringprep, to combat the IDN spoofing problem.

The IDN WG did explore that, in depth; it's all in the archives. You 
may disagree with the conclusion, but please don't minimize the 
difficult decision-making that went into the protocol design and 
development.

>Third, there seems to be some resistance to continuing IDN work in 
>the IETF space.

Correct. Without some indication of what the work is, how it relates 
to current protocols, and who will do it, there is resistance. If 
those three are made clear, the IETF could be much more interested. 
The same is true for any standards organization.

>  So, an Internet Draft may not be appropriate.

Internet Drafts are always appropriate, even if the work is being 
done somewhere else. They give a single place to look for the latest 
version. Yes, they have formatting and can't-always-publish issues, 
but they usually work well.

>  Michel has indicated that the Unicode Consortium is working on the 
>homograph problem, so maybe we can place our bets there.

They are working on specifying the problem and listing some proposed 
solutions. They are not working on protocol changes.

>rules (i.e. RFC 3743 "JET"), then they can of course do so. I 
>certainly do not want to have a balkanized net, but the degree of 
>balkanization is what matters. I.e. if we only have 2 methods (CJK 
>vs the rest), that's better than having numerous methods.

Many people spent a lot of work trying to get coordination and/or 
cooperation for creating those lists. So far, the results have been 
less than stellar. The cultural imperatives and political exigencies 
make that work very, very difficult despite all the good effort.

--Paul Hoffman, Director

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Feb 2005 14:50:17 -0500

--On Thursday, 17 February, 2005 11:16 -0800 Paul Hoffman
<[email-masked]> wrote:

>> Alternatively, if some registries (e.g. CJK) wish to have
>> their own  rules (i.e. RFC 3743 "JET"), then they can of
>> course do so. I  certainly do not want to have a balkanized
>> net, but the degree of  balkanization is what matters. I.e.
>> if we only have 2 methods (CJK  vs the rest), that's better
>> than having numerous methods.
> 
> Many people spent a lot of work trying to get coordination
> and/or cooperation for creating those lists. So far, the
> results have been less than stellar. The cultural imperatives
> and political exigencies make that work very, very difficult
> despite all the good effort.

Erik,

Let me agree with Paul here (!), especially about the cultural
imperatives and political expediencies.   But I think your
comment about "numerous methods" deserves some additional
response.  Let me try to put the JET work,
draft-klensin-reg-guidelines, the ICANN guidelines, and a few
other registration-side efforts in perspective.

Registries have always (since long before IDNs and, for the old
host tables, even before the DNS) been able to say "there are
names that we will not permit to be registered here" and/or
"there are entities we will not permit to register here" and/or
"that entity can register, but only with one of these names".
Beyond enforcement of the "hostname" (or "LDH") rule --neither
of which is "English" but which is, itself, a registration
restriction, there has been no uniformity among domains about
what those rules are and how vigorously they are enforced.
We've seen rules about length that are more restrictive than the
DNS limit, rules about national presence, rules about
registration only of names that appear in national business
registers, rules about prohibited "nasty" words, and so on for a
very long list.

That isn't just about TLDs:  I've got biases about names in
jck.com, and I enforce them... and so do a rather large fraction
of the enterprise and other domain administrators in the world
whose domains consist of labels for more than a couple of hosts
or functions.

None of these rules or conventions causes any interoperability
(or balkanization) issues at all: a resolver either finds the
name or doesn't, and is indifferent to whether a name that is
not found isn't there because no one wanted to register it or
because they were prohibited from doing so.

We would have interoperability issues if someone tried to change
the resolution rules themselves: a local (and different) version
of the IDNA tables that would map a UTF-8-encoded Unicode string
to a different punycode string than is called for by the IDNA
and nameprep specs would be very bad news indeed.  So would
installing a DNS server that would use a set of lookup and
matching rules different from those required by 1034/1035.  But
people rarely propose such things and, so far, we have been
fairly successful at talking them out of it when they do...
precisely because such actions would balkanize the network.

So, in general, having different sets of registry restriction
rules in different registries, even unique rules for each
registry, are not a problem.   Having individual applications
programs, such as browsers, guess what those rules are for a
given domain is, by contrast, a nightmare.  While warning the
user when certain types of anomalies are detected makes a lot of
sense, any sort of "bad name" restriction on a name that is
IDNA-conformant would be really bad news, going far beyond the
messes I tried to warn about in RFC 3696.

There are two groups of folks for whom different restrictions in
different registries are a problem.  They involve registrants
who want to register the same name in many domains and the
registrars who need to deal with them (and with those domains).
For the former, the fact that a name may be acceptable in some
domains and not others is tough luck.  It has always been tough
luck: IDNs may expand the number of possible reasons for
rejection, but they don't introduce any new problem.   For the
registrars, one level of service involves trying to understand
what all the rules are for any domain they support.  That is
tough, but not impossible.  Another level involves just sending
a proposed name in and seeing if it is accepted.  They are, for
most domains, in a very competitive environment; the marketplace
will presumably sort out the best combination of service levels
and pricing.  The one piece of that issue that is an IETF story
is that we should try to design registrar-registry
communications protocols to deliver good information back to the
registrar as to why a particular proposed name is being
rejected.   My impression is that we are doing that reasonably
well but that we should keep looking for ways to improve things
while keeping them general.  

But, again, no interoperability or balkanization problems here
unless someone starts making changes to the resolution or
matching protocols or models.

    john

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 13:40:54 -0800

> because they were prohibited from doing so.

Yes, but as a browser developer, I *would* care about whether a user was 
able to easily type in a domain name and go where s/he wanted to go. In 
the presence of these homograph problems, a browser developer might even 
want to retry DNS lookups with different character codes until it 
succeeded. We can't just foist these solvable problems on the end-user.

> and nameprep specs would be very bad news indeed.

You could use a prefix other than xn-- to migrate from the old to the 
new. I jotted down a few quick ideas here:

http://lists.w3.org/Archives/Public/www-international/2005JanMar/0101.html

However, if I can't get support from the major organizations such as 
Microsoft, VeriSign and the Unicode Consortium (either because too many 
xn-- names have already been registered and the migration would not be 
practical or for some other reason), then I might just give up on this 
idea. But I'm willing to explore it some more.

> Having individual applications
> given domain is, by contrast, a nightmare.

As a browser developer, I would not try to "guess" what those rules are. 
I would read them and try to implement them correctly.

> any sort of "bad name" restriction on a name that is

Gotta go right now. I'll read that later.

Erik

---

From: Erik van der Poel <[email-masked]>
Date: Thu, 17 Feb 2005 19:07:58 -0800

> this mailing list (myself included) are facile with alternate DNS 

Actually, I'm not interested in such a DNS record. I was merely trying 
to point out that Eric's original phrase "dns tricks" could be 
interpreted differently (i.e. different from Adam's and your 
interpretation). Maybe Eric could clarify his original email (if he 
wishes to do so).

>> nameprep are 2 amazing pieces of work, but I feel they did not go far 
>> enough. I think it is probably worth exploring whether we might map 
>> homographs to "base" characters in a new "prep", perhaps another 
> The IDN WG did explore that, in depth; it's all in the archives. You may 
> disagree with the conclusion, but please don't minimize the difficult 
> decision-making that went into the protocol design and development.

It sounds like I upset you (and/or other people), and I'm sorry.

>> IETF space.
> Correct. Without some indication of what the work is, how it relates to 
> current protocols, and who will do it, there is resistance. If those 
> three are made clear, the IETF could be much more interested. The same 
> is true for any standards organization.

When I first read this a few hours ago, I thought you were slamming the 
door shut on me, but on closer reading, it seems that that is not the case.

>> balkanization is what matters. I.e. if we only have 2 methods (CJK vs 
>> the rest), that's better than having numerous methods.
> 
> cooperation for creating those lists. So far, the results have been less 
> than stellar. The cultural imperatives and political exigencies make 
> that work very, very difficult despite all the good effort.

Here again I must apologize to all the parties concerned. My comments 
were insensitive, and I hope not to repeat this mistake.

Erik

---

From: Martin Duerst <[email-masked]>
Date: Fri, 18 Feb 2005 11:52:43 +0900

Hello Eric,

 >Yes, but as a browser developer, I *would* care about whether a user was 
able to easily type in a domain name and go where s/he wanted to go. In the 
presence of these homograph problems, a browser developer might even want 
to retry DNS lookups with different character codes until it succeeded. We 
can't just foist these solvable problems on the end-user.

As a browser developer, you don't even have to care too much about
ease of typing, above and beyond making sure that the user can use
the input facilities provided by the OS and Windowing system,...
in the usual way.

The rest will be taken care by registrants, they'll figure out
sooner or later what names are easy to type and what names are
not easy to type. It has worked quite well for the ASCII-only
DNS.

[rethorical question:]
Are we also going to deal with those cases in US-ASCII that can
be confusing now?

Later, Martin v. Loevis wrote:
>The most natural keyboard input in this case is the apparent
>script of the label. The user should see the script from reading
>it

Yes. And some labels where the script isn't clear enough might
not get registered by honest folks because they want users to
understand how to type things, rather than to worry what
script to use. An alternative may of course be registering
in both scripts.
[the number of cases that this applies are probably not
large, I'm mainly thinking about short words or company
names/acronyms in Russian and similar places]

Regards,   Martin.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 18 Feb 2005 13:19:59 +0100

>not easy to type. It has worked quite well for the ASCII-only

Welcome to "phish and click" !!!

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Feb 2005 10:06:43 -0500

> Welcome to "phish and click" !!!

Which, as Martin points out, has worked quite well for the
ASCII-only DNS.

   john

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Fri, 18 Feb 2005 11:29:18 -0500 (EST)

Thank you for the thoughtful comments.  I'm going to cherry pick and just 
respond to the assertions I think are most germane to my original comment. 
(There's lots of other interesting issues, but not for here and now.)

1. I'm glad you recognize I am not advocating an enforcement regime. And I 
like consensus when we can get it.  But I also don't mind market-based 
regimes with clear disclosure and labelling; in a managed space with 
artificial scarcity like the TLD-space, one way to get that is to increase 
supply. I recognize that some people are nervous about that, but it 
doesn't seem to dennigrate those concerns to also note that there can be 
advantages.

2. I do, however, disgree with the assertion that the gTLD space we have, 
or even the gTLD + ccTLD space, is a well-functioning competitive market 
at the registry level for reasons including first-mover advantages, 
locking, arbitrary semantic choices imposed by the regulator (ICANN) and 
so on.  I could go on, or cite academic papers, but I know that you and 
the others who care have heard the arguments.  I thus also think that 
in this environment there is little one can infer by registration 
patterns, which are driven by other things.

3. If we want or hope for innovative marketing or differentiation of 
gTLDs, the most likely way to get them is to create new ones.  The IETF, 
and if memory serves you prominently among its active members, has 
expressed scepticism about this idea on many occasions.

4. The idea for an informational RFC in this area is no odder than, say, 
RFC 3675 (which is not intended as a comment on the merits of that 
document, but just a comment about its scope as it relates to the scope 
of this idea)...or even, dare I say it, RFC 3071.

5. I agree there would be a substantial drafting challenge to be overcome.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 18 Feb 2005 16:54:08 +0100

>Which, as Martin points out, has worked quite well for the

And will work much better for IDNA which offers far more phishing and 
tricks opportunities.

Welcome to the IETF understanding of 
internationalization/multiligualization/vernacularization !!!
And you are the one who understand it the best....
Never asked: did you work with Doug Engelbart too?
jfc

PS. By the way where did you take that IDNA was not using an ASCII-only DNS?
That international/multilingual/vernacular layers are much simpler when 
using ASCII domain name does not imply that they do not exist and that you 
are permitted layer violations.
Or may be you mean that a far better way was to respect the DNS basic 
rules, not to introduce as left to right contradicting hierachy (IDN/DN) 
and management mess? IMHO we do not need to worry: this is what a 
grassroots process is going to impose on the long/medium?/short?? range if 
they want to avoid a balkanization of the root.

Let get real. I do prefer "name.tag--eu.ch" being read "name.ech" by my 
browser/userbox tables than a multilingual root being linked to the NTIA 
root through an "*" entry. Do you know what is the size of a virus table 
maintained every morning on my PC when compared with a TLD language 
transcoding table? 260 TLDs, possibly 500 scripts = 2000 ITLDs for a 10 
chars entry average: 20000 chars.Good ASN.1 may reduce it. Compressed 
probably 10 K. I am sure every PAD Administrators will include it and the 
root file for free in their delivery. Sent as patches it probably takes 100 
bytes a day.