<<< Date Index >>>     <<< Thread Index >>>

Re: [alac] IDN document, draft 4



A few comments from my part, sorry for the delay.

Starting from the end, the last paragraph suggests the internationalization of the protocol string names. I am not sure that the solution should be a different script for http:, sip:, etc. Besides, this would need major changes in the way the protocols work. What we should state is the user need, not the solution, and namely the elimination (in perspective) of the need for typing any ascii-specific script. For instance, the need to be able to type on a keyboard that does not have any capability to produce asci chars. The difference is that the second formulation opens the possibility to intervene with standards at the browser (or client). The ascii protocol string name could be created by the browser in a way that is transparent to the user.

About point 8., how can ICANN enforce stopping registration of IDNs until proper policy is developed? If it does, it will end up in favouring the Saudi Arabian approach of the parallel root "for testing purposes". This is a veeeery dangerous direction.

I have severe doubts on 7. While I understand the point made, about "weakly supported" scripts, I don't think that the solution should be to enforce support by all registries of the (potentially thousands) scripts. We need to distinguish the need for producing tables for all recognized scripts, which will mean involvment of ISO as well, and keep it separated from the practical implementation. A similar argument otherwise would apply for global registries to do business in every country, regardless the local trading conditions. I am sufficiently confident that market pressure will make global registries adopt what has a reasonable case. After all, what is the point in developing a web site that has only a couple of dozens users? But if the community grows, and increases in numbers of potential web sites (or other usages for the names), at least the relevant ccTLD might elect to support the script. Anyway, if ICANN comes with the enforcement of the implementation of all possible scripts by gTLDs, the first things it will get is an outcry from the Registries, being called a bolscevist dictator, and possibly a lawsuit for imposition of unfair trade rules.

On the preambule, I basicaly agree with Thomas' comments. I would only add the risk for customers to be confused later on as an additional negative effect of unorderly developmetn of IDN. And to a certain extent, it is already so because of the different approaches that have been taken by different TLDs.

Last but not least, I have mixed feelings about the automatic registration of bundles of names. To be honest, I did not think through the issue sufficiently to have a qualified opinion. It looks to me a far bigger can of worms it looks at the surface.

Regards

Roberto GAETANO
ALAC
ICANN BoD Liaison




From: Vittorio Bertola <vb@xxxxxxxxxxxxxx>
To: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
CC: alac@xxxxxxxxx
Subject: Re: [alac] IDN document, draft 4
Date: Thu, 16 Dec 2004 07:56:51 +0100

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


_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/