Re: [alac] IDN document, draft 4

[Vittorio Bertola <vb@xxxxxxxxxxxxxx>]

I still owed some replies to Thomas and Wendy... I guess I will be working
on a draft 5 text later today.

Thomas:

>- In the second paragraph, the document says that "cultural and
>  political considerations should be given higher priority than
>  economical or technical ones".  Following this recipe would be
>  desastrous -- it basically calls for wishful thinking and politics
>  to ignore technical feasibility and business viability of new
>  technologies or policies.

The idea was just to remind that the current de facto priority list of the
GNSO - first, IP protection; second, selling more domains; ... last,
cultural diversity and i18n - should be reversed :) Anyway, I will revise
the wording.

>- The third paragraph suggests that, out of the fear that mistakes
>  may be made in the introduction of IDNs, due care must be taken;
>  in recommendation 8, this care then mutates into a call for
>  halting the registration of IDNs in gTLDs.  At the same time,
>  recommendation 8 turns the introductory sentence of the third
>  paragraph into mere lip service -- this leaves a bad taste with
>  me.
>
>  The pattern of this argument is remarkably similar to the one we
>  have been fighting with respect to the introduction of new gTLDs.
>  Applying it to earlier innovations on the net, and then looking at
>  what would have followed from it, makes for an interesting thought
>  argument.

I see a significant difference here: we are not asking ICANN to prevent
innovation, but just to ensure that proper policy is in place before doing
changes that can't easily be reverted. Also, we have shown that there could
be harm from uncoordinated broad introduction of IDNs.

More or less, it's the same principle for which, for example, the community
wanted to have UDRP in place before introducing new gTLDs - which doesn't
mean that we don't want new gTLDs, but just that we want to have the right
tools in place to prevent problems. Now, UDRP + sunrise periods might be the
right tools, and there could be no need for complex equivalences, but at
least you have to think at the problem before the oxen are let out of the
stable.

So I can't see how you could recommend this and that policy if then you say
"oh, but by the way, you have already started to sell domains so all of this
will remain dead on paper". If no policy is required or even allowed before
innovation, we might as well close ICANN, let everything in the capable
hands of the "market" (i.e. Verisign) and go home!

>- Recommendation 1 misses the fact that similar or identical scripts
>  are used differently in different language contexts. Consequently,
>  confusion opportunities will also be different in different TLDs.
>  
>  I do not believe that we have done the research (or gathered the
>  expertise) that would be necessary to make this wide-ranging
>  recommendation.  Please turn this into a recommendation that the
>  viability of common variant tables be researched.

Makes sense.

>- The relationship between recommendation 1 and recommendation 2 is
>  unclear.  Don't they contradict each other?

No, it means "The affected community develops the 'best practice' table [2]
and then the others possibly adopt it [1]".

>- Recommendation 6 does, on the substance (sunrise/block for 
>  equivalence classes which contain a latin-only name that has
>  already been registered) sound well.  The example, however, makes
>  the assumption that the crude romanizations in use now would
>  automatically be included with equivalences.  It is not at all
>  clear that this assumption is warranted.  Hence, the example needs
>  to go.

I'd rather add an "if" clause, but I think that without an example nobody
will even understand the problem.

Wendy:

>Overall, I think it's unhelpful to reinforce the notion that "squatters" 
>are the most pressing concern about domain names.  Avoidance of confusion 
>is valuable, but much confusion is a matter of initial expectations, and I 
>just don't know enough about all the languages' use of variant scripts to 
>know how likely confusion is.

Well, I can tell you that even in a just slightly extended Western script
like Italian, which is ASCII + five accented vowels that are used only at
the end of words, we have been stuck about IDNs exactly because we had to
decide the acceptable compromise between complexity and protection of
existing registrations. The day after IETF published the choice of "xn--",
there immediately were people trying to register the xn-- string
corresponding to the "correctly accented" version of some well known domain
names that had the misfortune of using romanized versions of italian words
containing the accented letter. The ccTLD had to pass rules in a rush to
prevent registration of any string starting with xn--, and since then we are
discussing how to proceed. The likely outcome is that we might have a
sunrise period to let the owners of the romanized versions claim the correct
ones, but then we will possibly not add any equivalence to the system.
(Which might as well be an acceptable outcome for a linguistic community...
but only after some discussion on the problem, not if imposed by ICANN's
lack of policy or attention for the problem.)

   Some languages may give different, equally 
>valid, meanings to two variants that look alike to untrained eyes; avoiding 
>confusion in one script may deprive another of useful domain names.   For 
>that reason, your point 3 seems impossible to define uniformly, and thus 
>the paragraphs that follow from it utopian.

Shouldn't someone should first look into it before making conclusions?

>Cultural and political respect is important, but I would not say it's more 
>important than technical function, which should always be ICANN's paramount 
>concern.  Again, I'm not sure whether others feel that multiplication of 
>scripts is among ICANN's most pressing concerns.  To me, it isn't.  I'd 
>much rather see a minimal ICANN helping to oversee a technically well-run 
>and competitive Internet, than a body with larger scope trying to 
>everything proposed here.

Well, if you talk to most non-English-speaking people in the WSIS context,
their priorities for ICANN are 1) get rid of the USG supervision and 2)
IDNs. For example, things like new ASCII gTLDs never come up, and they are
often seen like a waste of time. So I guess it's a matter of personal
priorities - but ICANN should be able to satisfy the expectation of all its
users.

>I'm not sure why it's critical that all gTLDs be translated.  Ten years 
>down the road, I don't think it would be unrealistic to see (finally) a 
>profusion of TLDs, in which choice could be enriched by their offering 
>different options.  It's entirely possible -- and not necessarily a bad 
>thing -- that some wouldn't use ASCII script and would therefore be 
>difficult to type on a U.S. keyboard.  To me, the strongest support for 
>translatability would be a policy that all domains should be able to 
>interconnect easily with all others.  Have we ever articulated such a policy?

What do you mean by "interconnect"?

>I know the vision that domain names should be merely labels, not imbued 
>with semantic meaning, is equally utopian, but it's my utopia :)

The problem now is that they have semantic meaning if you understand Western
scripts - and this makes the Internet much easier to use to Western people
than to others. The prevailing opinion seems to be that this is absolutely
unfair.
-- 
vb.               [Vittorio Bertola - v.bertola [a] bertola.eu.org]<------
http://bertola.eu.org/  <- Vecchio sito, nuovo toblòg...