Re: [gnso-idng] rethinking IDN gTLDs

[Avri Doria <avri@xxxxxxx>]

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.

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.

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