RE: [gnso-idng] rethinking IDN gTLDs

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

Further comments below

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On
> Behalf Of Gomes, Chuck
> 
> Please see my responses below.
> 
> Chuck
> 
> > -----Original Message-----
> > From: owner-gnso-idng@xxxxxxxxx
> > [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> >
> >
> > Hi,
> >
> > I guess I see a few issues on these second level schemes, among them
> >
> > 1. There may still be confusion about what a user gets when
> > using these names.  The registrant may be the same so they
> > are probably not being phished, but still there are many
> > issues like what is the equivalent in another language/script
> > of most names. Several distinct names may have similar translations.
> 
> Chuck: That is true but that deals with the initial selection of string
> and after that it is a matter of communication and education. Besides, I
> don't believe that the new gTLD confusing similiarity restriction solves
> the problem you are talking about anyway.  The point you make certainly
> illustrates that it is very important for an existing gTLD operator to
> do due diligence in selection its IDN strings so as to maximise
> effectiveness and minimize confusion of the registrants in its
> namespace.
> 

Edmon: I think Avri you probably mistook the idea... I think what Chuck and
I were talking about is NOT about translation at the second level.  But
offering the same string to the same registrant under an IDN TLD.  More
specifically, for example, a registrant of "computer.asia" will be offered
"computer.???" (where "???" is "Asia" in Japanese), OR a registrant for
"???????.asia" (where "???????" means "Internet" in Japanese) will be
offered "???????.???".  There is no translation involved.

> >
> > 2. There seem to be a large number of possible ways to handle
> > the equivalences, each with somewhat different behavior.  Do
> > these need to be reviewed individually to make sure they do
> > not create more problems then they solve.
> 
> Chuck: Are you talking about equivalence at the second or top level?
> Assuming you mean the second level, in the case of VeriSign's plan, we
> are taking about exact at the second level. Otherwise we get into a
> nearly possible situation where we have to make subjective judgements.
> If a registrant wants to protect variations of its domain name, it will
> be necessary to register each of the variations at least once in either
> the LDH or IDN version of the TLD.
>

Edmon: Answer for #1 above probably clarifies this.  Again, there is no
translation involved.  Therefore equivalence is handled by having the same
string and not some semantic translation.


Edmon



> >
> > Also on the first level, I think we are still assuming the
> > these similarities is one of meaning, not visual or even
> > aural.  Since ambiguity of meaning is a vast issue as things
> > rarely translate that directly, how is one to disambiguate
> > between the translations, for example, of .com and .biz, .
> > So by saying that some names that may mean something close
> > are the same as another and sometimes they are different, is
> > in itself confusing.
> >
> > a.
> >
> > On 2 Dec 2009, at 01:25, Eric Brunner-Williams wrote:
> >
> > >
> > > To offer a different example, an existing registry with an
> > existing pre-validation process and eligibility model, could
> > provide the pre-validation process and eligibility model --
> > "the policy" -- to an applicant for the same (or more
> > culturally correct) string in a script other than Latin.
> > >
> > > Chuck's example is an equivalence of a subset of a zone in
> > a second or subsequent zones with a common operator.
> > >
> > > My example is an equivalent policy across two or more zones
> > with possibly distinct operators.
> > >
> > > It is a challenge to find where user confusion arises in
> > either planned plurality across multiple name spaces with a
> > common operator, or policy consistency across multiple name
> > spaces with disjoint operators.
> > >
> > > In both cases, all domain names for the ASCII and IDN
> > namespaces will have the same registrant, or no registrant.
> > Of course, the underlying resource records may point to the
> > registrant's script-specific resources.
> > >
> > > Eric
> >
> >
> >