Re: [alac] IDN document, draft 4

["Roberto Gaetano" <alac_liaison@xxxxxxxxxxx>]

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/