ICANN ICANN Email List Archives

[At-Large Advisory Committee]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [alac] IDN document, draft 4

  • To: Vittorio Bertola <vb@xxxxxxxxxxxxxx>
  • Subject: Re: [alac] IDN document, draft 4
  • From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
  • Date: Mon, 13 Dec 2004 12:29:54 +0100

Some remarks as I go through the document:

- 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.
  
  Do we really want to run IDNs (and, by extension, the net) on
  government funding?

  I would say that "cultural and political considerations should be
  given due priority", but I would not declare them absolutes.
  
  (For the record, this is an objection against the second
  paragraph in its current form.)

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

  Hint: I wouldn't write this message (and would probably do
  mathematics for a living) if this kind of argument had pervailed
  in the past twenty to thirty years.

  (For the record, this is an objection against the third
  paragraph's essential direction.)

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

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

- In recommendation 3, the text says that "not defining any
  equivalences is an unacceptable policy, because it would prevent
  the adoption of any anti-cybersquatting and anti-confusion
  measures." This is simply wrong.

  (Think "confusing similarity" -- it seems naïve to me to even
  assume that decisions on fuzzy criteria such as confusion or
  similarity could be made on the basis of hard and fast rules;
  ultimately, this will always be a judgment call.)

  Please strike this part of the argument.

- Recommendation 4 is ok when "equivalence" is dealt with properly.

- 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 continue to object against recommendation 8, and request that my
  objection be included with any published non-draft version of the
  document that includes recommendation 8.

- In recommendation 9, the word "promptly" seems misplaced, in
  particular in a context in which ALAC (wrongly) calls for the
  suspension of IDN registrations.  "Can be reached in a timely
  manner" would be more appropriate.

Regards,
-- 
Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy